Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports
From: Steven Rostedt
Date: Tue, 28 Jan 2014 15:57:56 -0500
> At Red Hat we base our real-time kernel off of 3.10.27 and do lots of
> stress testing on that kernel. This has discovered some bugs that we
> can hit with the vanilla 3.10.27 kernel (no -rt patches applied).
>
> I sent out a bug fix that can cause a crash with the current 3.10.27
> when you add and then remove the sit module. That patch is obsoleted by
> these patches, as that patch was not enough.
>
> A previous patch that was backported:
>
> Upstream commit 205983c43700ac3a81e7625273a3fa83cd2759b5
> sit: allow to use rtnl ops on fb tunnel
>
> Had a depenency on commit 5e6700b3bf98 ("sit: add support of x-netns")
> which was not backported. The dependency was only on part of that
> commit which is what I backported.
>
> The other upstream commit 9434266f2c645d4fcf62a03a8e36ad8075e37943
> sit: fix use after free of fb_tunnel_dev
>
> fixes another bug we encountered, it also fixes the 3.10.27 bug
> where removing the sit module cause the crash. This is the patch
> that obsoletes my previous patch.
Greg, these have my blessing, please apply these to 3.10 -stable,
thanks a lot!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8 v4] crypto:s5p-sss: Use clk_prepare/clk_unprepare
Hello Sylwester, On 23 January 2014 16:11, Sylwester Nawrocki wrote: > Hi, > > On 23/01/14 11:18, Naveen Krishna Ch wrote: >> Hello All, >> >> On 15 January 2014 14:47, Naveen Krishna Chatradhi >> wrote: >>> This patch set adds use of clk_prepare/clk_unprepare as >>> required by generic clock framework. >>> >>> Signed-off-by: Naveen Krishna Chatradhi >>> Reviewed-by: Tomasz Figa >>> --- >>> Changes since v3: >>> None >>> >>> drivers/crypto/s5p-sss.c |6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c >>> index f7c66c7..870e794 100644 >>> --- a/drivers/crypto/s5p-sss.c >>> +++ b/drivers/crypto/s5p-sss.c >>> @@ -648,7 +648,7 @@ static int s5p_aes_probe(struct platform_device *pdev) >>> return -ENOENT; >>> } >>> >>> - clk_enable(pdata->clk); >>> + clk_prepare_enable(pdata->clk); > > How about properly checking the return value ? Sure, Thanks. > > -- > Thanks, > Sylwester -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers: ide: Include appropriate header file in ide-pio-blacklist.c
From: Rashika Kheria Date: Tue, 17 Dec 2013 16:41:11 +0530 > Include appropriate header file include/linux/ide.h in file > ide-pio-blacklist.c because function ide_scan_pio_blacklist() has it's > prototype declaration in include/linux/ide.h. > > This eliminates the following warning in ide-pio-blacklist.c: > drivers/ide/ide-pio-blacklist.c:85:5: warning: no previous prototype for > ‘ide_scan_pio_blacklist’ [-Wmissing-prototypes] > > Signed-off-by: Rashika Kheria Applied.
Re: [PATCH 1/2] drivers: ide: Include appropriate header file in ide-cd_verbose.c
From: Rashika Kheria Date: Tue, 17 Dec 2013 16:38:16 +0530 > Include appropriate header file ide-cd.h in ide-cd_verbose.c because > function ide_cd_log_error() has its prototype declaration in ide-cd.h. > Also, include linux/ide.h because it contains certain declarations > necessary for including ide-cd.h. > > This eliminates the following warnings in ide-cd_verbose.c: > drivers/ide/ide-cd_verbose.c:251:6: warning: no previous prototype for > ‘ide_cd_log_error’ [-Wmissing-prototypes] > > Signed-off-by: Rashika Kheria Applied.
Re: [PATCH] i2c-designware-pcidrv: fix the incorrect return of idle callback
于 2014年01月29日 10:03, xinhui.pan 写道: > >> On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote: >>> From: "xinhui.pan" >>> >>> i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do >>> success. >> >> I don't understand... >> > Sorry for my poor English. > Even if i2c_dw_pci_runtime_idle succeed ,it should return -EBUSY. >>> Otherwise rpm_idle will call pm_suspend again and that may cause >>> pm_schedule_suspend delay invalidate. >>> >>> Signed-off-by: bo.he >>> Signed-off-by: xinhui.pan >>> --- >>> drivers/i2c/busses/i2c-designware-pcidrv.c |4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c >>> b/drivers/i2c/busses/i2c-designware-pcidrv.c >>> index f6ed06c..96e81f6 100644 >>> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c >>> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c >>> @@ -190,8 +190,8 @@ static int i2c_dw_pci_runtime_idle(struct device *dev) >>> int err = pm_schedule_suspend(dev, 500); >>> dev_dbg(dev, "runtime_idle called\n"); >>> >>> - if (err != 0) >>> - return 0; >>> + if (err) >>> + return err; >>> return -EBUSY; >> >> ... it does return EBUSY when pm_schedule_suspend() succeeds? It only >> returns 0 if it does not succeed (for which I don't know if this is an >> apropriate behaviour). Mika? >> hi , I found one sentence in /Documentation/power/runtime_pm.txt "If there is no idle callback, or if the callback returns 0, then the PM core will attempt to carry out a runtime suspend of the device, also respecting devices configured for autosuspend." so is this a right way to prevent this? Br. xinhui >>> } >>> >>> -- >>> 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] reproducable ubifs reboot assert and corruption
Am 29.01.2014 06:32, schrieb Andrew Ruder: > Ok, I've got some more useful information. I have been adding > a multitude of WARN_ON's and prink's all over the remount code and have > come up with the attached log. > > A little bit of explanation: > > Line 1: sync_filesystem (from do_remount_sb) > Line 188: sync_filesystem ends > Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur > during sync_filesystem. Before each warning I print the inode pointer. > Line 197: read-only remount has completely finished (this message is > from userspace post remount) > Line 199: a sync is called, there are apparently dirty inodes in our > now-readonly ubifs filesystem > Line 215: failed assert that occurs because the writeback triggers for > inode 0xd75b9450 (see line 41, it got in with a sys_write while we were > running our sync_filesystem in do_remount_sb) > > Does this help? It looks like there is a race condition between the > writeback code and the remount read-only. Nothing is done to lock out > writes during the first half of the do_remount_sb and some stuff makes > it into the writeback worker queue while we are busy syncing the > filesystem only to trigger later when ubifs has decided it is > read-only... > > Note: I only barely know what I am talking about - filesystems still not > my forte :) BTW: Can you please share your .config? Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: export __clk_get_hw for re-use in others
On Wed, 22 Jan 2014, SeongJae Park wrote: > Oops, I've forgot about the merge window. Thank you very much for your > kind answer. > Sorry if I bothered you while you're in busy time. > Because the build problem is not a big deal because it exists only in > -next tree, This problem exists in Linus's tree, not only in -next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] power_supply: bq24261 charger driver
On Wednesday, January 29, 2014 10:24 PM, Jenny Tc wrote:
> On Tue, Jan 28, 2014 at 07:14:45AM -0700, Pavel Machek wrote:
> > > +#define BQ24261_ICHRG_MASK (0x1F << 3)
> > > +#define BQ24261_ICHRG_100ma (0x01 << 3)
> > > +#define BQ24261_ICHRG_200ma (0x01 << 4)
> > > +#define BQ24261_ICHRG_400ma (0x01 << 5)
> > > +#define BQ24261_ICHRG_800ma (0x01 << 6)
> > > +#define BQ24261_ICHRG_1600ma (0x01 << 7)
> >
> > First, its mA, not ma.
>
> Camel Case allowed? Ignore Checkpatch.pl warning?
Yep, Camel Case is allowed by the commit d8b0771 "checkpatch:
extend CamelCase types and ignore existing CamelCase uses in
a patch".
Thus, the following cases are currently allowed.
#define BQ24261_ICHRG_1600ma (0x01 << 7)
#define BQ24261_ICHRG_1600MA (0x01 << 7)
#define BQ24261_ICHRG_1600mA (0x01 << 7)
Best regards,
Jingoo Han
> > > +u16 bq24261_iterm[][2] = {
> > > + {0, 0x00}
> > > + ,
> > > + {50, BQ24261_ITERM_50ma}
> > > + ,
> > > + {100, BQ24261_ITERM_100ma}
> > > + ,
> > > + {150, BQ24261_ITERM_100ma | BQ24261_ITERM_50ma}
> >
> > ...this is very obscure way to do with table what can be done with
> >
> > (x/50) << 3, right ?
>
> Few register settings need table mapping, but some can have logic as your
> comment say. Just wanted to keep same logic for all register settings.
> Doesn't it make more readable?
>
> > > +u16 bq24261_cc[][2] = {
> > > +
> > > + {500, 0x00}
> > > + ,
> > > + {600, BQ24261_ICHRG_100ma}
> > > + ,
> > > + {700, BQ24261_ICHRG_200ma}
> > > + ,
> > > + {800, BQ24261_ICHRG_100ma | BQ24261_ICHRG_200ma}
> > > + ,
> > > + {900, BQ24261_ICHRG_400ma}
> >
> > I suspect you can get rid of this, too, if you expand macros.
> Same as above comment.
>
> -Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio-intel-mid: fix the incorrect return of idle callback
于 2014年01月29日 08:13, David Cohen 写道:
> On Tue, Jan 28, 2014 at 12:12:06PM -0600, Felipe Balbi wrote:
>> On Tue, Jan 28, 2014 at 09:24:13AM -0800, David Cohen wrote:
>>> On Tue, Jan 28, 2014 at 10:49:37AM -0600, Felipe Balbi wrote:
On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> From: "xinhui.pan"
>
> intel_gpio_runtime_idle should return correct error code if it do fail.
> make it more correct even though -EBUSY is the most possible return value.
>
> Signed-off-by: bo.he
> Signed-off-by: xinhui.pan
> ---
> drivers/gpio/gpio-intel-mid.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
> index d1b50ef..05749a3 100644
> --- a/drivers/gpio/gpio-intel-mid.c
> +++ b/drivers/gpio/gpio-intel-mid.c
> @@ -394,7 +394,9 @@ static const struct irq_domain_ops intel_gpio_irq_ops
> = {
>
> static int intel_gpio_runtime_idle(struct device *dev)
> {
> - pm_schedule_suspend(dev, 500);
> + int err = pm_schedule_suspend(dev, 500);
> + if (err)
> + return err;
> return -EBUSY;
wait, is it only me or this would look a lot better as:
static int intel_gpio_runtime_idle(struct device *dev)
{
return pm_schedule_suspend(dev, 500);
}
>>>
>>> The reply to your suggestion is probably in this commit :)
>>>
>>> ---
>>> commit 45f0a85c8258741d11bda25c0a5669c06267204a
>>> Author: Rafael J. Wysocki
>>> Date: Mon Jun 3 21:49:52 2013 +0200
>>>
>>> PM / Runtime: Rework the "runtime idle" helper routine
>>> ---
>>>
>>> We won't return 0 from here.
>>
>> so you never want to return 0, why don't you, then:
>>
>> static int intel_gpio_runtime_idle(struct device *dev)
>> {
>> pm_schedule_suspend(dev, 500);
>> return -EBUSY;
>> }
>
> That's how it is currently :)
>
> But this patch is making the function to return a different code in case
> of error. IMHO there is not much fuctional gain with it, but I see
> perhaps one extra info for tracing during development.
>
> Anyway, I'll let Xinhui to do further comment since he's the author.
>
> Br, David
>
hi ,David & Balbi
I checked several drivers yesterday to see how they use pm_schedule_suspend
then found one bug in i2c. Also I noticed gpio.
I think returning a correct error code is important.So I change -EBUSY
to *err*. To be honest,current code works well.
>>
>> just like drivers/tty/serial/mfd.c::serial_hsu_runtime_idle() is doing ?
>>
>> --
>> balbi
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in numa_clear_kernel_node_hotplug().
* Gu Zheng wrote:
> Hi Ingo,
> On 01/28/2014 07:48 PM, Ingo Molnar wrote:
>
> >
> > * David Rientjes wrote:
> >
> >> On Tue, 28 Jan 2014, Tang Chen wrote:
> >>
> >>> On-stack variable numa_kernel_nodes in numa_clear_kernel_node_hotplug()
> >>> was not initialized. So we need to initialize it.
> >>>
> >>> Signed-off-by: Tang Chen
> >>> Tested-by: Gu Zheng
> >>
> >> Reported-by: David Rientjes
> >
> > Agreed. Tang Chen, please also spell it out in the changelog:
> >
> >David Rientjes reported a boot crash, caused by
> >commit XYZ ("foo: bar").
> >
> > I find it somewhat annoying that you found time to credit a corporate
> > collegue with a Tested-by tag, who didn't even reply to the whole
> > thread to indicate his testing efforts,
>
> Sorry for missing to indicate the test result, because I am really
> busy with some thorny issues. If Tang did not remind me, maybe I'll
> miss the whole thread. But I think the "Tested-by:" is the best
> confirmation of the testing efforts, it indicates that the guy has
> nearly completely tested the patch on his environment.
Thanks for the effort!
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: another perf_fuzzer soft lockup
* Vince Weaver wrote: > After some idle time I've started running the perf_fuzzer again. > > It quickly found this lockup on a core2 system running 3.13 (yes, I > should probably be running 3.14-git but I'd rather wait for rc1 > first). JFYI, if -git looks too dangerous to you (and I cannot blame you for that view in the middle of a merge window) then tip:master is usually a pretty safe substitute for testing, it's the v3.14 perf code on a v3.13 base. > It looks like it's stuck in a lock in generic_exec_single() while > calling perf_event_task_output()? > > I'll try to see if I can come up with a test case. Thanks, those testcases are always very useful! 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: [BUG] reproducable ubifs reboot assert and corruption
Am 29.01.2014 06:32, schrieb Andrew Ruder: > Ok, I've got some more useful information. I have been adding > a multitude of WARN_ON's and prink's all over the remount code and have > come up with the attached log. > > A little bit of explanation: > > Line 1: sync_filesystem (from do_remount_sb) > Line 188: sync_filesystem ends > Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur > during sync_filesystem. Before each warning I print the inode pointer. > Line 197: read-only remount has completely finished (this message is > from userspace post remount) > Line 199: a sync is called, there are apparently dirty inodes in our > now-readonly ubifs filesystem > Line 215: failed assert that occurs because the writeback triggers for > inode 0xd75b9450 (see line 41, it got in with a sys_write while we were > running our sync_filesystem in do_remount_sb) > > Does this help? It looks like there is a race condition between the > writeback code and the remount read-only. Nothing is done to lock out > writes during the first half of the do_remount_sb and some stuff makes > it into the writeback worker queue while we are busy syncing the > filesystem only to trigger later when ubifs has decided it is > read-only... So you can trigger this by running fsstress on /mnt and then call mount -o remount,ro /mnt? Can you also trigger it on nandsim or mtdram? I did a quick test on my testbed using mtdram and was unable to trigger it. But I fear my box is too fast. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] net: ethoc: set up MII management bus clock
Le 28/01/2014 22:00, Max Filippov a écrit :
MII management bus clock is derived from the MAC clock by dividing it by
MIIMODER register CLKDIV field value. This value may need to be set up
in case it is undefined or its default value is too high (and
communication with PHY is too slow) or too low (and communication with
PHY is impossible). The value of CLKDIV is not specified directly, but
is derived from the MAC clock for the default MII management bus frequency
of 2.5MHz. The MAC clock may be specified in the platform data, or as
either 'clock-frequency' or 'clocks' device tree attribute.
Signed-off-by: Max Filippov
---
Changes v1->v2:
- drop MDIO bus frequency configurability, always configure for standard
2.5MHz;
- allow using common clock framework to provide ethoc clock.
drivers/net/ethernet/ethoc.c | 37 +++--
include/net/ethoc.h | 1 +
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5643b2d..5854d41 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -216,6 +217,7 @@ struct ethoc {
struct phy_device *phy;
struct mii_bus *mdio;
+ struct clk *clk;
s8 phy_id;
};
@@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
int num_bd;
int ret = 0;
bool random_mac = false;
+ u32 eth_clkfreq = 0;
+ struct ethoc_platform_data *pdata = dev_get_platdata(>dev);
/* allocate networking device */
netdev = alloc_etherdev(sizeof(struct ethoc));
@@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
}
/* Allow the platform setup code to pass in a MAC address. */
- if (dev_get_platdata(>dev)) {
- struct ethoc_platform_data *pdata =
dev_get_platdata(>dev);
+ if (pdata) {
memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
priv->phy_id = pdata->phy_id;
} else {
@@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device *pdev)
if (random_mac)
netdev->addr_assign_type = NET_ADDR_RANDOM;
+ /* Allow the platform setup code to adjust MII management bus clock. */
+ if (pdata)
+ eth_clkfreq = pdata->eth_clkfreq;
Since this is a new member, why not make it a struct clk pointer
directly so you could simplify the code path?
+ else
+ of_property_read_u32(pdev->dev.of_node,
+"clock-frequency", _clkfreq);
+ if (!eth_clkfreq) {
+ struct clk *clk = clk_get(>dev, NULL);
+
+ if (!IS_ERR(clk)) {
+ priv->clk = clk;
+ clk_prepare_enable(clk);
+ eth_clkfreq = clk_get_rate(clk);
+ }
+ }
+ if (eth_clkfreq) {
+ u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 250 + 1);
+
+ if (!clkdiv)
+ clkdiv = 2;
+ dev_dbg(>dev, "setting MII clkdiv to %u\n", clkdiv);
+ ethoc_write(priv, MIIMODER,
+ (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE) |
+ clkdiv);
+ }
This does look a bit convoluted, and it looks like the clk_get() or
getting the clock-frequency property should boil down to being the same
thing with of_clk_get() as it should resolve all clocks phandles and
fetch their frequencies appropriately.
+
/* register MII bus */
priv->mdio = mdiobus_alloc();
if (!priv->mdio) {
@@ -1141,6 +1170,8 @@ free_mdio:
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
free:
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
This should probbaly be if (!IS_ERR(priv-clk)).
free_netdev(netdev);
out:
return ret;
@@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device *pdev)
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
}
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
Same here
unregister_netdev(netdev);
free_netdev(netdev);
}
diff --git a/include/net/ethoc.h b/include/net/ethoc.h
index 96f3789..2a2d6bb 100644
--- a/include/net/ethoc.h
+++ b/include/net/ethoc.h
@@ -16,6 +16,7 @@
struct ethoc_platform_data {
u8 hwaddr[IFHWADDRLEN];
s8 phy_id;
+ u32 eth_clkfreq;
};
#endif /* !LINUX_NET_ETHOC_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 v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
On Wed, Jan 29, 2014 at 10:47 AM, Florian Fainelli wrote: > Hi Max, > > Le 28/01/2014 22:00, Max Filippov a écrit : > >> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does >> not disable advertisement when PHY supports them. This results in >> non-functioning network when the MAC is connected to a gigabit PHY >> connected >> to a gigabit switch. >> >> The fix is to disable gigabit speed advertisement on attached PHY >> unconditionally. >> >> Signed-off-by: Max Filippov >> --- >> Changes v1->v2: >> - disable both gigabit advertisement and support. >> >> drivers/net/ethernet/ethoc.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c >> index 4de8cfd..5643b2d 100644 >> --- a/drivers/net/ethernet/ethoc.c >> +++ b/drivers/net/ethernet/ethoc.c >> @@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev) >> } >> >> priv->phy = phy; >> + phy_update_advert(phy, >> + ADVERTISED_1000baseT_Full | >> + ADVERTISED_1000baseT_Half, 0); >> + phy_start_aneg(phy); > > > This does not look necessary, you should not have to call phy_start_aneg() > because the PHY state machine is not yet started, at best this calls does > nothing. This call actually makes the whole thing work, because otherwise once gigabit support is cleared from the supported mask genphy_config_advert does not update gigabit advertisement register, leaving it enabled. >> + phy_update_supported(phy, >> +SUPPORTED_1000baseT_Full | >> +SUPPORTED_1000baseT_Half, 0); >> + >> return 0; >> } >> >> > -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
Le 28/01/2014 22:00, Max Filippov a écrit :
The following methods are implemented:
- get/set settings;
- get registers length/registers;
- get link state (standard implementation);
- get/set ring parameters;
- get timestamping info (standard implementation).
Ideally you should have one patch per ethtool callback that you
implement just in case something happens to break, only the specific
patch can reverted/referenced.
Signed-off-by: Max Filippov
---
Changes v1->v2:
- new patch.
drivers/net/ethernet/ethoc.c | 85
1 file changed, 85 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5854d41..2f8b174 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -52,6 +52,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
#define ETH_HASH0 0x48
#define ETH_HASH1 0x4c
#define ETH_TXCTRL 0x50
+#defineETH_END 0x54
/* mode register */
#define MODER_RXEN (1 << 0) /* receive enable */
@@ -180,6 +181,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
* @membase: pointer to buffer memory region
* @dma_alloc:dma allocated buffer size
* @io_region_size: I/O memory region size
+ * @num_bd:number of buffer descriptors
* @num_tx: number of send buffers
* @cur_tx: last send buffer written
* @dty_tx: last buffer actually sent
@@ -200,6 +202,7 @@ struct ethoc {
int dma_alloc;
resource_size_t io_region_size;
+ unsigned int num_bd;
unsigned int num_tx;
unsigned int cur_tx;
unsigned int dty_tx;
@@ -900,6 +903,86 @@ out:
return NETDEV_TX_OK;
}
+static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_gset(phydev, cmd);
+}
+
+static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_sset(phydev, cmd);
+}
+
+static int ethoc_get_regs_len(struct net_device *netdev)
+{
+ return ETH_END;
+}
+
+static void ethoc_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ u32 *regs_buff = p;
+ unsigned i;
+
+ regs->version = 0;
+ for (i = 0; i < ETH_END / sizeof(u32); ++i)
+ regs_buff[i] = ethoc_read(priv, i * sizeof(u32));
+}
+
+static void ethoc_get_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ ring->rx_max_pending = priv->num_bd;
+ ring->rx_mini_max_pending = 0;
+ ring->rx_jumbo_max_pending = 0;
+ ring->tx_max_pending = priv->num_bd;
+
+ ring->rx_pending = priv->num_rx;
+ ring->rx_mini_pending = 0;
+ ring->rx_jumbo_pending = 0;
+ ring->tx_pending = priv->num_tx;
+}
+
+static int ethoc_set_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ if (netif_running(dev))
+ return -EBUSY;
+ priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
+ priv->num_rx = priv->num_bd - priv->num_tx;
+ if (priv->num_rx > ring->rx_pending)
+ priv->num_rx = ring->rx_pending;
+ return 0;
+}
+
+const struct ethtool_ops ethoc_ethtool_ops = {
+ .get_settings = ethoc_get_settings,
+ .set_settings = ethoc_set_settings,
+ .get_regs_len = ethoc_get_regs_len,
+ .get_regs = ethoc_get_regs,
+ .get_link = ethtool_op_get_link,
+ .get_ringparam = ethoc_get_ringparam,
+ .set_ringparam = ethoc_set_ringparam,
+ .get_ts_info = ethtool_op_get_ts_info,
+};
+
static const struct net_device_ops ethoc_netdev_ops = {
.ndo_open = ethoc_open,
.ndo_stop = ethoc_stop,
@@ -1028,6 +,7 @@ static int ethoc_probe(struct platform_device *pdev)
ret = -ENODEV;
goto error;
}
+ priv->num_bd = num_bd;
/* num_tx must be a power of two */
priv->num_tx = rounddown_pow_of_two(num_bd >> 1);
priv->num_rx = num_bd - priv->num_tx;
@@ -1148,6 +1232,7 @@ static int ethoc_probe(struct platform_device *pdev)
netdev->netdev_ops = _netdev_ops;
netdev->watchdog_timeo = ETHOC_TIMEOUT;
netdev->features |= 0;
+ netdev->ethtool_ops = _ethtool_ops;
/* setup NAPI */
netif_napi_add(netdev, >napi, ethoc_poll, 64);
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
Hi Max, Le 28/01/2014 22:00, Max Filippov a écrit : OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does not disable advertisement when PHY supports them. This results in non-functioning network when the MAC is connected to a gigabit PHY connected to a gigabit switch. The fix is to disable gigabit speed advertisement on attached PHY unconditionally. Signed-off-by: Max Filippov --- Changes v1->v2: - disable both gigabit advertisement and support. drivers/net/ethernet/ethoc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c index 4de8cfd..5643b2d 100644 --- a/drivers/net/ethernet/ethoc.c +++ b/drivers/net/ethernet/ethoc.c @@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev) } priv->phy = phy; + phy_update_advert(phy, + ADVERTISED_1000baseT_Full | + ADVERTISED_1000baseT_Half, 0); + phy_start_aneg(phy); This does not look necessary, you should not have to call phy_start_aneg() because the PHY state machine is not yet started, at best this calls does nothing. + phy_update_supported(phy, +SUPPORTED_1000baseT_Full | +SUPPORTED_1000baseT_Half, 0); + return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: slub: fix page->_count corruption (again)
On Tue, Jan 28, 2014 at 03:52:47PM -0800, Dave Hansen wrote: > On 01/28/2014 03:29 PM, Andrew Morton wrote: > > On Tue, 28 Jan 2014 15:17:22 -0800 Dave Hansen wrote: > > This code is borderline insane. > > No argument here. > > > Yes, struct page is special and it's worth spending time and doing > > weird things to optimise it. But sheesh. > > > > An alternative is to make that cmpxchg quietly go away. Is it more > > trouble than it is worth? > > It has measurable performance benefits, and the benefits go up as the > cost of en/disabling interrupts goes up (like if it takes you a hypercall). > > Fengguang, could you run a set of tests for the top patch in this branch > to see if we'd be giving much up by axing the code? > > > https://github.com/hansendc/linux/tree/slub-nocmpxchg-for-Fengguang-20140128 Sure, I've queued tests for the branch. Will report back after 1-2 days. Thanks, Fengguang > I was talking with one of the distros about turning it off as well. > They mentioned that they saw a few performance regressions when it was > turned off. I'll share details when I get them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipv6: default route for link local address is not added while assigning a address
Resending this on netdev mailing list:
Default route for link local address is configured automatically if
NETWORKING_IPV6=yes is in ifcfg-eth*.
When the route table for the interface is flushed and a new address is
added to the same device with out removing linklocal addr, default route
for link local address has to added by default.
I have found the issue to be caused by this checkin
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
According to this change :
He removes adding a link local route if any other address is added ,
applicable across all interfaces though there's mentioned only lo interface
So below patch fixes for other devices
Signed-off-by: Sohny THomas
-
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f62c72b..a8a4df9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1763,6 +1763,16 @@ static int addrconf_ifid_infiniband(u8 *eui,
struct net_device *dev)
return 0;
}
+static void addrconf_add_lroute(struct net_device *dev)
+{
+ struct in6_addr addr;
+
+ ipv6_addr_set(, htonl(0xFE80), 0, 0, 0);
+ addrconf_prefix_route(, 64, dev, 0, 0);
+}
+
+
+
static int __ipv6_isatap_ifid(u8 *eui, __be32 addr)
{
if (addr == 0)
@@ -2010,8 +2020,10 @@ static struct inet6_dev *addrconf_add_dev(struct
net_device *dev)
return ERR_PTR(-EACCES);
/* Add default multicast route */
- if (!(dev->flags & IFF_LOOPBACK))
+ if (!(dev->flags & IFF_LOOPBACK)){
addrconf_add_mroute(dev);
+ addrconf_add_lroute(dev);
+ }
return idev;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/kaslr for v3.14
On Tue, 2014-01-28 at 16:08 -0500, Dave Jones wrote: > On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote: > > On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote: > > > > > > Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO? > > > Something like: > > > > > > "You don't need to enable this if you want symbolic names for kernel > > > objects. Enable CONFIG_KALLSYMS instead." > > > > Probably. And then we should make sure that allyesconfig/allmodconfig > > don't pick it. > > > > There *are* reasonable uses for DEBUG_INFO: > > > > - if you very actively and extensively use kgdb, DEBUG_INFO is very > useful. > > > > - distros might want to build distro kernels with DEBUG_INFO for the > > kernel debug package > > - objdump -S is kind of useful. I find myself using that quite often. > (like at least a dozen times each merge window) For those with wimpy asm muscles (/me), it's very useful indeed, as are gdb list *foo()+0x10 or *0xfeedbabedeadbeef. I always build with full DEBUG_INFO, just keep configs lean enough that lots of kernels fit in a 2G /boot, and _never ever_ set a box up with a microscopic root. > pretty sure it works with DEBUG_INFO_REDUCED though, which is somewhat > faster than full DEBUG_INFO Yeah, it does. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHSET v2 cgroup/for-3.15] cgroup: drop module support and cgroup_root_mutex
On 2014/1/29 7:43, Tejun Heo wrote:
> Hello,
>
> This is the second take. Changes from the last take[L] are
>
> * Updated to reflect changes in fe1217c4f3f7 ("net: net_cls: move
> cgroupfs classid handling into core").
>
> * Rebased on top of the current linus#master + some cgroup fix
> patches.
>
> There's only one controller which makes use of the module support -
> net_prio, which, non-coincidentally, isn't an actual resource
> controller. It's highly unlikely that the actual resource controlling
> controllers are gonna be made modular and we aren't gonna add more
> non-resource controllers either, so the value of module support is
> strictly restricted to the particular controller.
>
> The controller is fairly simple while module support in cgroup core
> adds quite a bit of complexity. Building the one controller as module
> only saves less than half-page in vmlinux, which really can't justify
> the additional complexity and (minute but existing) runtime overhead.
>
> This patchset makes net_prio config options bool so that it can't be
> built as modules and drops module support from cgroup core, which in
> turn facilitates further simplification leading to removal of
> cgroup_root_mutex by allowing iterating subsystems outside the
> mutexes.
>
> This patchset contains the following six patches.
>
> 0001-cgroup-make-CONFIG_CGROUP_NET_PRIO-bool-and-drop-unn.patch
> 0002-cgroup-drop-module-support.patch
> 0003-cgroup-clean-up-cgroup_subsys-names-and-initializati.patch
> 0004-cgroup-rename-cgroup_subsys-subsys_id-to-id.patch
> 0005-cgroup-update-locking-in-cgroup_show_options.patch
> 0006-cgroup-remove-cgroup_root_mutex.patch
>
> 0001-0002 drop cgroup module support.
>
> 0003-0004 are cleanups.
>
> 0005-0006 remove cgroup_root_mutex.
>
Acked-by: Li Zefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
Hi, On Monday 27 January 2014 07:49 PM, Yuvaraj Kumar C D wrote: > This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA > PHY comprises of CMU and TRSV blocks which are of I2C register Map. > So this patch also adds a i2c client driver, which is used configure > the CMU and TRSV block of exynos5250 SATA PHY. > > This patch incorporates the generic PHY framework to deal with SATA > PHY. > > This patch depends on the below patches > [1].drivers: phy: add generic PHY framework > by Kishon Vijay Abraham I It no longer should be mentioned here as it is already in mainline. Moreover these information shouldn't be in commit log. Just move it below '---'. > [2].ata: ahci_platform: Manage SATA PHY > by Roger Quadros > > Signed-off-by: Yuvaraj Kumar C D > Signed-off-by: Girish K S > Signed-off-by: Vasanth Ananthan > --- > Changes from V6: > 1.Removed phy-exynos5250-sata-i2c.c,as it is not required > after moving to of_find_i2c_device_by_node(). > 2.Changed struct __iomem *pmureg tp struct regmap *pmureg. > 3.Changed the wait_for_reg_status() to return 0 or -EFAULT. > > Changes from V5: > 1.Rebased on latest generic PHY framework for-next tree. > 2.Minor nits such as indentations. > > Changes from V4: > 1.Made Exynos5250 SATA PHY driver by default selects > CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver > depends on I2C. > 2.struct i2c_driver sataphy_i2c_driver made static which > was earlier global type. > 3.Renamed the files to phy-exynos5250-sata.c and > phy-exynos5250-sata-i2c.c and CONFIG_EXYNOS5250_SATA_PHY > to CONFIG_PHY_EXYNOS5250_SATA. > > Changes from V3: > 1.Moved devm_phy_create before to devm_phy_provider_register. > > Changes from V2: > 1.Removed of_match_table > 2.Moved to syscon interface for PMU handling. > > Changes from V1: > 1.Adapted to latest version of Generic PHY framework > 2.Removed exynos_sata_i2c_remove function. > > drivers/phy/Kconfig | 13 ++ > drivers/phy/Makefile |1 + > drivers/phy/phy-exynos5250-sata.c | 244 > + > 3 files changed, 258 insertions(+) > create mode 100644 drivers/phy/phy-exynos5250-sata.c > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index d0611b8..df79150 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -57,4 +57,17 @@ config PHY_EXYNOS_DP_VIDEO > help > Support for Display Port PHY found on Samsung EXYNOS SoCs. > > +config PHY_EXYNOS5250_SATA > + tristate "Exynos5250 Sata SerDes/PHY driver" > + depends on SOC_EXYNOS5250 > + select GENERIC_PHY > + select I2C > + select I2C_S3C2410 depends on HAS_IOMEM and depends on OF. > + select MFD_SYSCON > + help > + Enable this to support SATA SerDes/Phy found on Samsung's > + Exynos5250 based SoCs.This SerDes/Phy supports SATA 1.5 Gb/s, > + SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds. It supports one SATA host > + port to accept one SATA device. > + > endmenu > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 4e4adc9..5d93dc9 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -8,3 +8,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += > phy-exynos-mipi-video.o > obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o > obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o > obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o > +obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o > diff --git a/drivers/phy/phy-exynos5250-sata.c > b/drivers/phy/phy-exynos5250-sata.c > new file mode 100644 > index 000..b35168d > --- /dev/null > +++ b/drivers/phy/phy-exynos5250-sata.c > @@ -0,0 +1,244 @@ > +/* > + * Samsung SATA SerDes(PHY) driver > + * > + * Copyright (C) 2013 Samsung Electronics Co., Ltd. > + * Authors: Girish K S > + * Yuvaraj Kumar C D > + * > + * 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 > +#include > +#include > +#include > +#include > + > +#define EXYNOS5_SATA_RESET 0x4 > +#define RESET_CMN_RST_N (1 << 1) use BIT macro here and below. > +#define LINK_RESET 0xf > +#define EXYNOS5_SATA_MODE0 0x10 > +#define EXYNOS5_SATAPHY_PMU_ENABLE (1 << 0) > +#define SATA_SPD_GEN3(2 << 0) > +#define EXYNOS5_SATA_CTRL0 0x14 > +#define CTRL0_P0_PHY_CALIBRATED_SEL (1 << 9) > +#define CTRL0_P0_PHY_CALIBRATED (1 << 8) > +#define EXYNOS5_SATA_PHSATA_CTRLM0xe0 > +#define PHCTRLM_REF_RATE (1 << 1) > +#define
Re: [PATCH v2 0/4] OpenCores 10/100 MAC fixes for gigabit environment
Fixed the subject. On Wed, Jan 29, 2014 at 10:00 AM, Max Filippov wrote: > Hello David, Ben, Florian, Chris and everybody, > > this series improves ethoc behavior in gigabit environment: > - first patch introduces two phylib setters for 'advertising' and 'supported' > fields of struct phy_device; > - second patch disables gigabit advertisement in the attached PHY making > possible to use gigabit link without any additional setup; > - third patch adds support to set up MII management bus frequency, adding > new fields to platform data and to OF bindings; > - fourth patch adds basic ethtool support to ethoc driver. > > These changes allow to use KC-705 board with 50MHz xtensa core and OpenCores > 10/100 Mbps MAC connected to gigabit network without any additional setup. > > Changes v1->v2: > - new patch "phy: provide accessors for 'advertising' and 'supported' fields"; > - disable both gigabit advertisement and support; > - drop MDIO bus frequency configurability, always configure for standard > 2.5MHz; > - allow using common clock framework to provide ethoc clock; > - new patch: "net: ethoc: implement ethtool operations"; > - drop device tree bindings documentation patch until common bindings format > for network drivers is decided. > > Max Filippov (4): > phy: provide accessors for 'advertising' and 'supported' fields > net: ethoc: don't advertise gigabit speed on attached PHY > net: ethoc: set up MII management bus clock > net: ethoc: implement ethtool operations > > drivers/net/ethernet/ethoc.c | 130 > ++- > include/linux/phy.h | 12 > include/net/ethoc.h | 1 + > 3 files changed, 141 insertions(+), 2 deletions(-) > > -- > 1.8.1.4 -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Ceph updates for -rc1
Hi Linus, On Tue, 28 Jan 2014, Linus Torvalds wrote: > On Tue, Jan 28, 2014 at 1:10 PM, Dave Jones wrote: > > > > This breaks the build for me. > > It is my merge (Christoph's ACL changes came in today through the VFS > tree from Al). > > I was doing the merges today on my laptop (I had jury duty yesterday > and today), and so I didn't do the allmodconfig build I would normally > do on my (much faster) desktop. Well, actually I did do the full fs > builds for the earlier pulls that actually had some conflicts, but not > for the ceph pull. The conflict was hidden by the fact that the whole > cifs ACL support is new, so there was no data conflict, just a silent > semantic conflict between the new smarter ACL helpers and the new ACL > use in CIFS. s/cifs/ceph/ :) > I'm back home now (yay, all the afternoon cases got settled), and I > see the problem now. I should have done an allmodconfig build > immediately after coming home, but I never even thought of it. > > Anyway, here's an *untested* conversion to the new posix acl helper > infrastructure. I do wonder if ceph_init_acl() could be converted to > posix_acl_create(), right now that part is a "non-conversion" - it's > just made to use __posix_acl_create() that implements the old > interface. > > Al, Christoph, can you please check my conversion for sanity from a > generic posix-acl standpoint? > > Sage, Guangliang, Li, can you check the actual cifs usage/sanity of > the attached patch? Superficially at least the conversion looks okay to me, but it's not passing my smoke test (it's giving me EOPNOTSUPP for chmod and setxattr when setting an ACL). I'll look at it tomorrow if Guangliang, Li, or Yan don't get there first. I should have caught this before--I knew the ACL changes were coming and forgot to check the merged build beforehand! sage -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] phy: provide accessors for 'advertising' and 'supported' fields
Many network drivers directly modify phy_device::advertising and
phy_device::supported. Provide accessors to these fields to better
isolate phylib from its users.
Suggested-by: Ben Hutchings
Signed-off-by: Max Filippov
---
Changes v1->v2:
- new patch
include/linux/phy.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..2ae58f8 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -559,6 +559,18 @@ static inline int phy_read_status(struct phy_device
*phydev) {
return phydev->drv->read_status(phydev);
}
+static inline void phy_update_advert(struct phy_device *phydev, u32 clear,
+u32 set)
+{
+ phydev->advertising = (phydev->advertising & ~clear) | set;
+}
+
+static inline void phy_update_supported(struct phy_device *phydev, u32 clear,
+ u32 set)
+{
+ phydev->supported = (phydev->supported & ~clear) | set;
+}
+
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] net: ethoc: implement ethtool operations
The following methods are implemented:
- get/set settings;
- get registers length/registers;
- get link state (standard implementation);
- get/set ring parameters;
- get timestamping info (standard implementation).
Signed-off-by: Max Filippov
---
Changes v1->v2:
- new patch.
drivers/net/ethernet/ethoc.c | 85
1 file changed, 85 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5854d41..2f8b174 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -52,6 +52,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
#defineETH_HASH0 0x48
#defineETH_HASH1 0x4c
#defineETH_TXCTRL 0x50
+#defineETH_END 0x54
/* mode register */
#defineMODER_RXEN (1 << 0) /* receive enable */
@@ -180,6 +181,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
* @membase: pointer to buffer memory region
* @dma_alloc: dma allocated buffer size
* @io_region_size:I/O memory region size
+ * @num_bd:number of buffer descriptors
* @num_tx:number of send buffers
* @cur_tx:last send buffer written
* @dty_tx:last buffer actually sent
@@ -200,6 +202,7 @@ struct ethoc {
int dma_alloc;
resource_size_t io_region_size;
+ unsigned int num_bd;
unsigned int num_tx;
unsigned int cur_tx;
unsigned int dty_tx;
@@ -900,6 +903,86 @@ out:
return NETDEV_TX_OK;
}
+static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_gset(phydev, cmd);
+}
+
+static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_sset(phydev, cmd);
+}
+
+static int ethoc_get_regs_len(struct net_device *netdev)
+{
+ return ETH_END;
+}
+
+static void ethoc_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ u32 *regs_buff = p;
+ unsigned i;
+
+ regs->version = 0;
+ for (i = 0; i < ETH_END / sizeof(u32); ++i)
+ regs_buff[i] = ethoc_read(priv, i * sizeof(u32));
+}
+
+static void ethoc_get_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ ring->rx_max_pending = priv->num_bd;
+ ring->rx_mini_max_pending = 0;
+ ring->rx_jumbo_max_pending = 0;
+ ring->tx_max_pending = priv->num_bd;
+
+ ring->rx_pending = priv->num_rx;
+ ring->rx_mini_pending = 0;
+ ring->rx_jumbo_pending = 0;
+ ring->tx_pending = priv->num_tx;
+}
+
+static int ethoc_set_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ if (netif_running(dev))
+ return -EBUSY;
+ priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
+ priv->num_rx = priv->num_bd - priv->num_tx;
+ if (priv->num_rx > ring->rx_pending)
+ priv->num_rx = ring->rx_pending;
+ return 0;
+}
+
+const struct ethtool_ops ethoc_ethtool_ops = {
+ .get_settings = ethoc_get_settings,
+ .set_settings = ethoc_set_settings,
+ .get_regs_len = ethoc_get_regs_len,
+ .get_regs = ethoc_get_regs,
+ .get_link = ethtool_op_get_link,
+ .get_ringparam = ethoc_get_ringparam,
+ .set_ringparam = ethoc_set_ringparam,
+ .get_ts_info = ethtool_op_get_ts_info,
+};
+
static const struct net_device_ops ethoc_netdev_ops = {
.ndo_open = ethoc_open,
.ndo_stop = ethoc_stop,
@@ -1028,6 +,7 @@ static int ethoc_probe(struct platform_device *pdev)
ret = -ENODEV;
goto error;
}
+ priv->num_bd = num_bd;
/* num_tx must be a power of two */
priv->num_tx = rounddown_pow_of_two(num_bd >> 1);
priv->num_rx = num_bd - priv->num_tx;
@@ -1148,6 +1232,7 @@ static int ethoc_probe(struct platform_device *pdev)
netdev->netdev_ops = _netdev_ops;
netdev->watchdog_timeo = ETHOC_TIMEOUT;
netdev->features |= 0;
+ netdev->ethtool_ops = _ethtool_ops;
/* setup NAPI */
netif_napi_add(netdev, >napi, ethoc_poll, 64);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] net: ethoc: set up MII management bus clock
MII management bus clock is derived from the MAC clock by dividing it by
MIIMODER register CLKDIV field value. This value may need to be set up
in case it is undefined or its default value is too high (and
communication with PHY is too slow) or too low (and communication with
PHY is impossible). The value of CLKDIV is not specified directly, but
is derived from the MAC clock for the default MII management bus frequency
of 2.5MHz. The MAC clock may be specified in the platform data, or as
either 'clock-frequency' or 'clocks' device tree attribute.
Signed-off-by: Max Filippov
---
Changes v1->v2:
- drop MDIO bus frequency configurability, always configure for standard
2.5MHz;
- allow using common clock framework to provide ethoc clock.
drivers/net/ethernet/ethoc.c | 37 +++--
include/net/ethoc.h | 1 +
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5643b2d..5854d41 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -216,6 +217,7 @@ struct ethoc {
struct phy_device *phy;
struct mii_bus *mdio;
+ struct clk *clk;
s8 phy_id;
};
@@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
int num_bd;
int ret = 0;
bool random_mac = false;
+ u32 eth_clkfreq = 0;
+ struct ethoc_platform_data *pdata = dev_get_platdata(>dev);
/* allocate networking device */
netdev = alloc_etherdev(sizeof(struct ethoc));
@@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
}
/* Allow the platform setup code to pass in a MAC address. */
- if (dev_get_platdata(>dev)) {
- struct ethoc_platform_data *pdata =
dev_get_platdata(>dev);
+ if (pdata) {
memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
priv->phy_id = pdata->phy_id;
} else {
@@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device *pdev)
if (random_mac)
netdev->addr_assign_type = NET_ADDR_RANDOM;
+ /* Allow the platform setup code to adjust MII management bus clock. */
+ if (pdata)
+ eth_clkfreq = pdata->eth_clkfreq;
+ else
+ of_property_read_u32(pdev->dev.of_node,
+"clock-frequency", _clkfreq);
+ if (!eth_clkfreq) {
+ struct clk *clk = clk_get(>dev, NULL);
+
+ if (!IS_ERR(clk)) {
+ priv->clk = clk;
+ clk_prepare_enable(clk);
+ eth_clkfreq = clk_get_rate(clk);
+ }
+ }
+ if (eth_clkfreq) {
+ u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 250 + 1);
+
+ if (!clkdiv)
+ clkdiv = 2;
+ dev_dbg(>dev, "setting MII clkdiv to %u\n", clkdiv);
+ ethoc_write(priv, MIIMODER,
+ (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE) |
+ clkdiv);
+ }
+
/* register MII bus */
priv->mdio = mdiobus_alloc();
if (!priv->mdio) {
@@ -1141,6 +1170,8 @@ free_mdio:
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
free:
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
free_netdev(netdev);
out:
return ret;
@@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device *pdev)
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
}
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
unregister_netdev(netdev);
free_netdev(netdev);
}
diff --git a/include/net/ethoc.h b/include/net/ethoc.h
index 96f3789..2a2d6bb 100644
--- a/include/net/ethoc.h
+++ b/include/net/ethoc.h
@@ -16,6 +16,7 @@
struct ethoc_platform_data {
u8 hwaddr[IFHWADDRLEN];
s8 phy_id;
+ u32 eth_clkfreq;
};
#endif /* !LINUX_NET_ETHOC_H */
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does not disable advertisement when PHY supports them. This results in non-functioning network when the MAC is connected to a gigabit PHY connected to a gigabit switch. The fix is to disable gigabit speed advertisement on attached PHY unconditionally. Signed-off-by: Max Filippov --- Changes v1->v2: - disable both gigabit advertisement and support. drivers/net/ethernet/ethoc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c index 4de8cfd..5643b2d 100644 --- a/drivers/net/ethernet/ethoc.c +++ b/drivers/net/ethernet/ethoc.c @@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev) } priv->phy = phy; + phy_update_advert(phy, + ADVERTISED_1000baseT_Full | + ADVERTISED_1000baseT_Half, 0); + phy_start_aneg(phy); + phy_update_supported(phy, +SUPPORTED_1000baseT_Full | +SUPPORTED_1000baseT_Half, 0); + return 0; } -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4]
Hello David, Ben, Florian, Chris and everybody, this series improves ethoc behavior in gigabit environment: - first patch introduces two phylib setters for 'advertising' and 'supported' fields of struct phy_device; - second patch disables gigabit advertisement in the attached PHY making possible to use gigabit link without any additional setup; - third patch adds support to set up MII management bus frequency, adding new fields to platform data and to OF bindings; - fourth patch adds basic ethtool support to ethoc driver. These changes allow to use KC-705 board with 50MHz xtensa core and OpenCores 10/100 Mbps MAC connected to gigabit network without any additional setup. Changes v1->v2: - new patch "phy: provide accessors for 'advertising' and 'supported' fields"; - disable both gigabit advertisement and support; - drop MDIO bus frequency configurability, always configure for standard 2.5MHz; - allow using common clock framework to provide ethoc clock; - new patch: "net: ethoc: implement ethtool operations"; - drop device tree bindings documentation patch until common bindings format for network drivers is decided. Max Filippov (4): phy: provide accessors for 'advertising' and 'supported' fields net: ethoc: don't advertise gigabit speed on attached PHY net: ethoc: set up MII management bus clock net: ethoc: implement ethtool operations drivers/net/ethernet/ethoc.c | 130 ++- include/linux/phy.h | 12 include/net/ethoc.h | 1 + 3 files changed, 141 insertions(+), 2 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] audit: Add generic compat syscall support
Catalin,
Let me correct myself,
On 01/27/2014 09:15 PM, Catalin Marinas wrote:
On Mon, Jan 27, 2014 at 05:58:07AM +, AKASHI Takahiro wrote:
Catalin and audit maintainers,
On 01/23/2014 11:51 PM, Catalin Marinas wrote:
On Fri, Jan 17, 2014 at 08:03:15AM +, AKASHI Takahiro wrote:
diff --git a/lib/compat_audit.c b/lib/compat_audit.c
new file mode 100644
index 000..94f6480
--- /dev/null
+++ b/lib/compat_audit.c
@@ -0,0 +1,51 @@
+#include
+#include
+/* FIXME: this might be architecture dependent */
+#include
It most likely is architecture dependent.
I'm wondering what name is the most appropriate in this case.
Most archictures have __NR_xyz definitions in "unistd_32.h",
but arm64 doesn't have it, instead "unistd32." which contains
only __SYSCALL(xyz, NO). Confusing?
I don't think we should introduce a new file (or at least it should be
named something containing "audit" to make it clearer).
+int audit_classify_compat_syscall(int abi, unsigned syscall)
+{
+ switch (syscall) {
+#ifdef __NR_open
+ case __NR_open:
+ return 2;
+#endif
+#ifdef __NR_openat
+ case __NR_openat:
+ return 3;
+#endif
+#ifdef __NR_socketcall
+ case __NR_socketcall:
+ return 4;
+#endif
+ case __NR_execve:
+ return 5;
+ default:
+ return 1;
+ }
+}
BTW, since they aren't many, you could get the arch code to define
__NR_compat_open etc. explicitly and use these. On arm64 we have a few
of these defined to avoid name collision in signal handling code.
Again, most architecture have their own unistd32.h for compat system calls,
and use __NR_open-like naming.
It's unlikely for these archs to migrate to "generic compat" auditing,
but I believe that '__NR_open'-like naming is better because we may be able to
avoid
arch-specific changes even for future(?) syscall-related enhancements in audit.
In my compat_audit.c, all the entries in audit classes are derived from
asm-generic/audit_*.h,
where __NR_xyz are used to list the system calls. So it is not possible to use
__NR_compat_xyz
as far as we re-use those generic files.
(Obviously we don't want to duplicate those header files, that is,
audit_compat_*.h.)
I agree that we should not have similar but different files, like unist32.h and
unistd_32.h,
but it seems to be inevitable for our case. (That is the reason why I
dynamically generate unistd_32.h)
As for arch-specific header file name, "audit_unistd32.h" can be fine, but
people on other architectures
might be unhappy with such a name since they can commonly use unistd32.h
instead.
- Takahiro AKASHI
My preference is as above, a few __NR_compat_* (just those required by
audit) defined in unistd.h but I'm not an audit maintainer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Query: Phy: How to find consumer device on dt platform
Hi,
On Wednesday 29 January 2014 02:56 AM, Arnd Bergmann wrote:
> On Tuesday 28 January 2014, Kishon Vijay Abraham I wrote:
>>> I have a common set of registers, which need to be programmed
>>> differently for PCIe and SATA during phy init/exit.
>>
>> One way is differentiate using different compatible strings fro pcie and sata
>> and use of_device_is_compatible to select a particular path.
>
> But if the IP block is the same, the compatible string should be
> identical.
Actually we define the compatible for 'device' no?. Here the same IP is
configured differently as different devices in SoCs.
>
>>> Therefore, in the init/exit routine of phy_ops, I need some way of
>>> identifying that phy_init/exit has been called from PCIe driver or
>>> SATA driver.
>>
>> In this case you'll be actually registering two different PHYs (each for pcie
>> and sata), so your phy_get should give you the only the appropriate phy.
>
> I would instead recommend making the mode of the PHY device the
> argument to the phy handle in DT, so that the sata node uses
>
> phys = < 0>;
>
> and the PCIe node uses
>
> phys = < 1>;
>
> Then the binding for the phy defines that an argument of '0' means sata mode,
> while '1' means pcie mode, plus you should define all other valid modes.
Anyway phyA and phyB points to different nodes and just from phyA and phyB we
should be able to tell whether it is sata or pcie.
We can just have a property in phyA to specify it is SATA and phyB to specify
it is PCIE.
phyA {
compatible="phy-pipe3";
.
.
type=;
}
phyB {
compatible="phy-pipe3";
.
.
type=;
}
Then in probe
of_property_read_u32(node, "type", >type);
In phy_init function we can follow different path for SATA and PCIE using the
type
static int pipe3_init(struct phy *x) {
struct pipe3 *phy = phy_get_drvdata(x);
switch (phy->type) {
case SATA:
/* do sata phy initialization here*/
break;
case PCIE:
/* do pcie phy initialization here*/
break;
default:
dev_err(phy->dev, "phy type not supported\n");
}
return 0;
}
Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] reproducable ubifs reboot assert and corruption
Ok, I've got some more useful information. I have been adding a multitude of WARN_ON's and prink's all over the remount code and have come up with the attached log. A little bit of explanation: Line 1: sync_filesystem (from do_remount_sb) Line 188: sync_filesystem ends Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur during sync_filesystem. Before each warning I print the inode pointer. Line 197: read-only remount has completely finished (this message is from userspace post remount) Line 199: a sync is called, there are apparently dirty inodes in our now-readonly ubifs filesystem Line 215: failed assert that occurs because the writeback triggers for inode 0xd75b9450 (see line 41, it got in with a sys_write while we were running our sync_filesystem in do_remount_sb) Does this help? It looks like there is a race condition between the writeback code and the remount read-only. Nothing is done to lock out writes during the first half of the do_remount_sb and some stuff makes it into the writeback worker queue while we are busy syncing the filesystem only to trigger later when ubifs has decided it is read-only... Note: I only barely know what I am talking about - filesystems still not my forte :) Thanks, Andy 1: pre sync_filesystem 2: [ cut here ] 3: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 4: Modules linked in: 5: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 6: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 7: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 8: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 9: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 10: [] (warn_slowpath_null+0x2c/0x34) from [] (bdi_queue_work+0xc8/0x130) 11: [] (bdi_queue_work+0xc8/0x130) from [] (writeback_inodes_sb_nr+0xb4/0xd4) 12: [] (writeback_inodes_sb_nr+0xb4/0xd4) from [] (writeback_inodes_sb+0x30/0x34) 13: [] (writeback_inodes_sb+0x30/0x34) from [] (sync_filesystem+0x50/0xbc) 14: [] (sync_filesystem+0x50/0xbc) from [] (do_remount_sb+0xb8/0x1fc) 15: [] (do_remount_sb+0xb8/0x1fc) from [] (do_mount+0x2e8/0x81c) 16: [] (do_mount+0x2e8/0x81c) from [] (SyS_mount+0x94/0xc8) 17: [] (SyS_mount+0x94/0xc8) from [] (ret_fast_syscall+0x0/0x2c) 18: ---[ end trace c6e04f3813781dc3 ]--- 19: Adding tail 20: writeback_workfn d781c110 d700fe8c 21: inode: d75a2c30 22: inode: d75b8c30 23: [ cut here ] 24: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 25: Modules linked in: 26: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 27: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 28: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 29: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 30: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 31: [] (warn_slowpath_null+0x2c/0x34) from [] (bdi_queue_work+0xc8/0x130) 32: [] (bdi_queue_work+0xc8/0x130) from [] (sync_inodes_sb+0xbc/0x1bc) 33: [] (sync_inodes_sb+0xbc/0x1bc) from [] (sync_filesystem+0x88/0xbc) 34: [] (sync_filesystem+0x88/0xbc) from [] (do_remount_sb+0xb8/0x1fc) 35: [] (do_remount_sb+0xb8/0x1fc) from [] (do_mount+0x2e8/0x81c) 36: [] (do_mount+0x2e8/0x81c) from [] (SyS_mount+0x94/0xc8) 37: [] (SyS_mount+0x94/0xc8) from [] (ret_fast_syscall+0x0/0x2c) 38: ---[ end trace c6e04f3813781dc4 ]--- 39: Adding tail 40: writeback_workfn d781c110 d700fe9c 41: inode: d75b9450 42: [ cut here ] 43: WARNING: CPU: 0 PID: 651 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c() 44: Modules linked in: 45: CPU: 0 PID: 651 Comm: fsstress Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 46: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 47: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 48: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 49: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 50: [] (warn_slowpath_null+0x2c/0x34) from [] (__mark_inode_dirty+0x2dc/0x32c) 51: [] (__mark_inode_dirty+0x2dc/0x32c) from [] (__set_page_dirty_nobuffers+0xf4/0x110) 52: [] (__set_page_dirty_nobuffers+0xf4/0x110) from [] (ubifs_write_end+0x1c8/0x294) 53: [] (ubifs_write_end+0x1c8/0x294) from [] (generic_file_buffered_write+0x17c/0x260) 54: [] (generic_file_buffered_write+0x17c/0x260) from [] (__generic_file_aio_write+0x420/0x448) 55: [] (__generic_file_aio_write+0x420/0x448) from [] (generic_file_aio_write+0x68/0xac) 56: [] (generic_file_aio_write+0x68/0xac) from [] (ubifs_aio_write+0x17c/0x18c) 57: [] (ubifs_aio_write+0x17c/0x18c) from [] (do_sync_write+0x7c/0xa0) 58: [] (do_sync_write+0x7c/0xa0) from [] (vfs_write+0xe4/0x194) 59: [] (vfs_write+0xe4/0x194) from []
Re: [PATCH 4/4] power_supply: bq24261 charger driver
On Tue, Jan 28, 2014 at 07:14:45AM -0700, Pavel Machek wrote:
> > +#define BQ24261_ICHRG_MASK (0x1F << 3)
> > +#define BQ24261_ICHRG_100ma(0x01 << 3)
> > +#define BQ24261_ICHRG_200ma(0x01 << 4)
> > +#define BQ24261_ICHRG_400ma(0x01 << 5)
> > +#define BQ24261_ICHRG_800ma(0x01 << 6)
> > +#define BQ24261_ICHRG_1600ma (0x01 << 7)
>
> First, its mA, not ma.
Camel Case allowed? Ignore Checkpatch.pl warning?
> > +u16 bq24261_iterm[][2] = {
> > + {0, 0x00}
> > + ,
> > + {50, BQ24261_ITERM_50ma}
> > + ,
> > + {100, BQ24261_ITERM_100ma}
> > + ,
> > + {150, BQ24261_ITERM_100ma | BQ24261_ITERM_50ma}
>
> ...this is very obscure way to do with table what can be done with
>
> (x/50) << 3, right ?
Few register settings need table mapping, but some can have logic as your
comment say. Just wanted to keep same logic for all register settings.
Doesn't it make more readable?
> > +u16 bq24261_cc[][2] = {
> > +
> > + {500, 0x00}
> > + ,
> > + {600, BQ24261_ICHRG_100ma}
> > + ,
> > + {700, BQ24261_ICHRG_200ma}
> > + ,
> > + {800, BQ24261_ICHRG_100ma | BQ24261_ICHRG_200ma}
> > + ,
> > + {900, BQ24261_ICHRG_400ma}
>
> I suspect you can get rid of this, too, if you expand macros.
Same as above comment.
-Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Jan 29
On Wed, 29 Jan 2014 16:28:55 +1100 Stephen Rothwell wrote: > > Non-merge commits (relative to Linus' tree): 2689 > 3435 files changed, 215376 insertions(+), 61940 deletions(-) Actually: Non-merge commits (relative to Linus' tree): 2751 3315 files changed, 222970 insertions(+), 63268 deletions(-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpd1GFNelDzZ.pgp Description: PGP signature
linux-next: Tree for Jan 29
Hi all, Please do *not* add material destined for v3.15 to your linux-next included trees until after v3.14-rc1 is released. This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140128: Linus' tree gained a build failure for which I applied a supplied patch. The imx-mxs gained a conflict against the arm tree, but lost its complex merge conflicts and so is back. The powerpc tree still had its build failure. The btrfs tree gained a conflict against Linus' tree. The nfsd tree gained a conflict against Linus' tree. The clk tree gained a conflict against Linus' tree and a build failure so I used the version from next-20140128. The akpm-current tree gained a conflict against Linus' tree. The akpm tree lost several of its patches. Non-merge commits (relative to Linus' tree): 2689 3435 files changed, 215376 insertions(+), 61940 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 208 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d891ea23d520 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Applying: Ceph updates for -rc1 Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (d326b65c57d6 ARM: fix building with gcc 4.6.4) Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more reliably) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (77c14e512f53 Merge branch 'qlcnic') Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (e7729a415315 ALSA: hda - Fix silent output on MacBook Air 1,1) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (7d0d46da750a Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging driver-core.current/driver-core-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging staging.current/staging-linus (77d143de7581 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml) Merging char-misc.current/char-misc-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging input-current/for-linus (55df811f2066 Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid find
Re: [PATCH 1/3] sched: Move the priority specific bits into a new header file.
Hi Dongsheng, On Mon, 27 Jan 2014 17:15:37 -0500, Dongsheng Yang wrote: > Some bits about priority are defined in linux/sched/rt.h, but > some of them are not only for rt scheduler, such as MAX_PRIO. > > This patch move them all into a new header file, linux/sched/prio.h. > > Signed-off-by: Dongsheng Yang > --- > include/linux/sched.h | 4 > include/linux/sched/prio.h | 23 +++ > include/linux/sched/rt.h | 21 +++-- > 3 files changed, 30 insertions(+), 18 deletions(-) > create mode 100644 include/linux/sched/prio.h > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 68a0e84..ba1b732 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -3,6 +3,10 @@ > > #include > > +#ifndef _SCHED_PRIO_H > +#include > +#endif /* #ifndef _SCHED_PRIO_H */ It seems you don't need to use #ifndef-#endif pair to include a header file? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Is it ok for deferrable timer wakeup the idle cpu?
Hi, On Thu, Jan 23, 2014 at 11:22 AM, Viresh Kumar wrote: > Hi Guys, > > So the first question is why cpufreq needs it and is it really stupid? > Yes, it is stupid but that's how its implemented since a long time. It does > so to get data about the load on CPUs, so that freq can be scaled up/down. > > Though there is a solution in discussion currently, which will take > inputs from scheduler and so these background timers would go away. > But we need to wait until that time. > > Now, why do we need that for every cpu, while that for a single cpu might > be enough? The answer is cpuidle here: What if the cpu responsible for > running timer goes to sleep? Who will evaluate the load then? And if we > make this timer run on one cpu in non-deferrable mode then that cpu > would be waken up again and again from idle. So, it was decided to have > a per-cpu deferrable timer. Though to improve efficiency, once it is fired > on any cpu, timer for all other CPUs are rescheduled, so that they don't > fire before 5ms (sampling time).. How about simplifying this design by doing the below? 1. Since anyway cpufreq governors monitor load on the cpu once every 5ms, *tie it with tick_sched_timer*, which also gets deferred when the cpu enters nohz_idle. 2. To overcome the problem of running this job of monitoring the load on every cpu, have the *time keeping* cpu do it for you. The time keeping cpu has the property that if it has to go to idle, it will do so and let the next cpu that runs the periodic timer become the time keeper. Hence no cpu is prevented from entering nohz_idle and the cpu that is busy and first executes periodic timer will take over as the time keeper. The result would be: 1. One cpu at any point in time will be monitoring cpu load, at every sched tick as long as its busy. If it goes to sleep, then it gives up this duty and enters idle. The next cpu that runs the periodic timer becomes the cpu to monitor the load and will continue to do so as long as its busy. Hence we do not miss monitoring the cpu load. 2. This will avoid an additional timer for cpufreq. 3. It avoids sending IPIs each time this timer gets modified since there is just one CPU doing the monitoring. 4. The downside to this could be that we are stretching the functions of the periodic timer into the power management domain which does not seem like the right thing to do. Having said the above, the fix that Viresh has proposed along with the nohz_full condition that Frederick added looks to solve this problem. But just a thought on if there is scope to improve this part of the cpufreq code. What do you all think? Thanks Regards Preeti U Murthy > > I think below diff might get this fixed for you, though I am not sure if it > breaks something else. Probably Thomas/Frederic can answer here. > If this looks fine I will send it formally again: > > diff --git a/kernel/timer.c b/kernel/timer.c > index accfd24..3a2c7fa 100644 > --- a/kernel/timer.c > +++ b/kernel/timer.c > @@ -940,7 +940,8 @@ void add_timer_on(struct timer_list *timer, int cpu) > * makes sure that a CPU on the way to stop its tick can not > * evaluate the timer wheel. > */ > - wake_up_nohz_cpu(cpu); > + if (!tbase_get_deferrable(timer->base)) > + wake_up_nohz_cpu(cpu); > spin_unlock_irqrestore(>lock, flags); > } > EXPORT_SYMBOL_GPL(add_timer_on); > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [BUG?] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
On Tue, 28 Jan 2014, Konrad Rzeszutek Wilk wrote:
> diff --git a/drivers/xen/xen-acpi-processor.c
> b/drivers/xen/xen-acpi-processor.c
> index 7231859..7602229 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -46,7 +46,7 @@ module_param_named(off, no_hypercall, int, 0400);
> */
> static unsigned int nr_acpi_bits;
> /* Mutex to protect the acpi_ids_done - for CPU hotplug use. */
> -static DEFINE_MUTEX(acpi_ids_mutex);
> +static DEFINE_SPINLOCK(acpi_ids_lock);
> /* Which ACPI ID we have processed from 'struct acpi_processor'. */
> static unsigned long *acpi_ids_done;
> /* Which ACPI ID exist in the SSDT/DSDT processor definitions. */
> @@ -68,7 +68,7 @@ static int push_cxx_to_hypervisor(struct acpi_processor
> *_pr)
> int ret = 0;
>
> dst_cx_states = kcalloc(_pr->power.count,
> - sizeof(struct xen_processor_cx), GFP_KERNEL);
> + sizeof(struct xen_processor_cx), GFP_ATOMIC);
> if (!dst_cx_states)
> return -ENOMEM;
>
> @@ -149,7 +149,7 @@ xen_copy_pss_data(struct acpi_processor *_pr,
>sizeof(struct acpi_processor_px));
>
> dst_states = kcalloc(_pr->performance->state_count,
> - sizeof(struct xen_processor_px), GFP_KERNEL);
> + sizeof(struct xen_processor_px), GFP_ATOMIC);
> if (!dst_states)
> return ERR_PTR(-ENOMEM);
>
> @@ -275,9 +275,9 @@ static int upload_pm_data(struct acpi_processor *_pr)
> {
> int err = 0;
>
> - mutex_lock(_ids_mutex);
> + spin_lock(_ids_lock);
> if (__test_and_set_bit(_pr->acpi_id, acpi_ids_done)) {
> - mutex_unlock(_ids_mutex);
> + spin_unlock(_ids_lock);
> return -EBUSY;
> }
> if (_pr->flags.power)
> @@ -286,7 +286,7 @@ static int upload_pm_data(struct acpi_processor *_pr)
> if (_pr->performance && _pr->performance->states)
> err |= push_pxx_to_hypervisor(_pr);
>
> - mutex_unlock(_ids_mutex);
> + spin_unlock(_ids_lock);
> return err;
> }
> static unsigned int __init get_max_acpi_id(void)
Looks incomplete, what about the kzalloc() in
xen_upload_processor_pm_data() and kcalloc()s in check_acpi_ids()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: via-rhine: add OF bus binding
2014/1/29 Tony Prisk : > On 29/01/14 07:27, Alexey Charkov wrote: >> >> 2014/1/27 Rob Herring : >>> >>> On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov >>> wrote: This should make the driver usable with VIA/WonderMedia ARM-based Systems-on-Chip integrated Rhine III adapters. Note that these are always in MMIO mode, and don't have any known EEPROM. Signed-off-by: Alexey Charkov Signed-off-by: Roger Luethi --- .../devicetree/bindings/net/via-rhine.txt | 18 ++ drivers/net/ethernet/via/Kconfig | 2 +- drivers/net/ethernet/via/via-rhine.c | 293 + 3 files changed, 200 insertions(+), 113 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt new file mode 100644 index 000..684dd3a --- /dev/null +++ b/Documentation/devicetree/bindings/net/via-rhine.txt @@ -0,0 +1,18 @@ +* VIA Rhine 10/100 Network Controller + +Required properties: +- compatible : Should be "via,rhine" >>> >>> This should be more specific rather than... >>> +- reg : Address and length of the io space +- interrupts : Should contain the controller interrupt line +- rhine,revision : Rhine core revision, used to inform the + driver of quirks and capabilities to expect from + the device. Mimics the respective PCI attribute. >>> >>> having this property. The OF match table can then have the quirks set >>> based on compatible strings. >> >> Sounds fair. Do you think something like the following would fly? >> >> Required properties: >> - compatible : Should be "via,rhine-soc-vt8500" for integrated Rhine >> cores found in SoC's such as VIA VT8500, WonderMedia WM8950 and >> possibly others. These are listed as 1106:3106 rev. 0x84 on the >> virtual PCI bus under vendor-provided kernels. > > Does it need a special name? I would have assumed they are using their own > IP for the VT6105 or VT6106S. > Then you can use it to add quirks later on if needed. The problem is that I have no reliable source for the exact name of the IP block. The lookup table within the driver says that rev. 0x83 is VT6105_B0, and rev. 0x8A is VT6105L (and it doesn't contain any entry for 0x84, so our case gets treated as 0x83 currently). If we only differentiate them by the compatible string, I would be reluctant to call it vt6105 or vt6106 or whatever else without knowing for sure. Otherwise, if at some point we need to add any quirks specific to rev. 0x84, we wouldn't be able to do that without side-effects. Thoughts welcome :) Thanks, Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] power_supply: Add inlmt,iterm, min/max temp props
On Fri, Jan 24, 2014 at 08:25:19AM -0700, Dmitry Eremin-Solenikov wrote: > On 22/01/14 21:19, Jenny TC wrote: > > Add new power supply properties for input current, charge termination > > current, min and max temperature > > > > POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature > > POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature > > What is the difference from TEMP_ALERT_MIN/TEMP_ALERT_MAX ? > There is a difference in definitions, but what is the logical difference? TEMP_ALERT_MIN/MAX is to ALERT when temperature cross the threshold. TEMP_MIN/MAX is to stop charging/discharging when cross the threshold. > > > POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. > > Indicates > > the input current for a charging source. > > POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to > > detect > > the end of charge condition > > For both of them: > > 1) Please don't use obscure abbreviations Agreed > 2) Is this generic enough? I.e. besides your charge manager who will > use that? Generic and all charger drivers can use this. > > -- > With best wishes > Dmitry -Jenny -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 00/16] Volatile Ranges v10
Hi Hannes, It's interesting timing, I posted this patch Yew Year's Day and receives indepth design review Lunar New Year's Day. :) It's almost 0-day review. :) On Tue, Jan 28, 2014 at 07:03:59PM -0500, Johannes Weiner wrote: > Hello Minchan, > > On Thu, Jan 02, 2014 at 04:12:08PM +0900, Minchan Kim wrote: > > Hey all, > > > > Happy New Year! > > > > I know it's bad timing to send this unfamiliar large patchset for > > review but hope there are some guys with freshed-brain in new year > > all over the world. :) > > And most important thing is that before I dive into lots of testing, > > I'd like to make an agreement on design issues and others > > > > o Syscall interface > > Why do we need another syscall for this? Can't we extend madvise to Yeb. I should have written the reason. Early versions in this patchset had used madvise with VMA handling but it was terrible performance for ebizzy workload by mmap_sem's downside lock due to merging/split VMA. Even it was worse than old so I gave up the VMA approach. You could see the difference. https://lkml.org/lkml/2013/10/8/63 It might be not a good decision and someone might say that if mmap_sem is really headache, please fix it at first but as you know well, it's never simple problem. I hope if better idea or final decision comes in(ex, let's hold until someone fix mmap_sem scalability), I could follow that. > take MADV_VOLATILE, MADV_NONVOLATILE, and return -ENOMEM if something > in the range was purged? In that case, -ENOMEM would have duplicated meaning "Purged" and "Out of memory so failed in the middle of the system call processing" and later could be a problem so we need to return value to indicate how many bytes are succeeded so far so it means we need additional out parameter. But yes, we can solve it by modifying semantic and behavior (ex, as you said below, we could just unmark volatile successfully if user pass (offset, len) consistent with marked volatile ranges. (IOW, if we give up overlapping/subrange marking/unmakring usecase. I expect it makes code simple further). It's request from John so If he is okay, I'm no problem. And there was another reason to make hard reusing madvise. full puring VS partial purging If someone should regenerate full object without considering fault/alloc/zeroig(and many of people wanted it rather than partial) he would want to VOLATILE_RANGE_FULL purging while others(acutlly, only I) likes VOLATILE_RANGE_PARTIAL for allocators(ie, vrange-anon) because it's fair for every processes in allocator POV(fault + alloc + zeroing overhead). It's not implemented yet in this patchset but I thought it is worth discuss and if we want it, current madvise isn't enough. > > > o Not bind with vma split/merge logic to prevent mmap_sem cost and > > o Not bind with vma split/merge logic to avoid vm_area_struct memory > > footprint. > > VMAs are there to track attributes of memory ranges. Duplicating > large parts of their functionality and co-maintaining both structures > on create, destroy, split, and merge means duplicate code and complex > interactions. > > 1. You need to define semantics and coordinate what happens when the >vma underlying a volatile range changes. > >Either you have to strictly co-maintain both range objects, or you >have weird behavior like volatily outliving a vma and then applying >to a separate vma created in its place. > >Userspace won't get this right, and even in the kernel this is >error prone and adds a lot to the complexity of vma management. Current semantic is following as, Vma handling logic in mm doesn't need to know vrange handling because vrange's internal logic always checks validity of the vma but one thing to do in vma logic is only clearing old volatile ranges on creating new vma. (Look at [PATCH v10 02/16] vrange: Clear volatility on new mmaps) Acutally I don't like the idea and suggested following as. https://git.kernel.org/cgit/linux/kernel/git/minchan/linux.git/commit/?h=vrange-working=821f58333b381fd88ee7f37fd9c472949756c74e But John didn't like it. I guess if VMA size is really matter, maybe we can embedded the flag into somewhere field of vma(ex, vm_file LSB?) Anyway, what I want to say is that vma/vrange co-maintaining seem to be not bad. > > 2. If page reclaim discards a page from the upper end of a a range, >you mark the whole range as purged. If the user later marks the >lower half of the range as non-volatile, the syscall will report >purged=1 even though all requested pages are still there. True, The assumption is that basically, user should have a range per object but we gives flexibility for user to handle subranges of a volatile range so it might report false positive as you said. In that case, please user can use mincore(2) for accuracy if he want so he has flexiblity but lose performance a bit. It's a tradeoff, IMO. > >The only way to make these semantics clean is either > > a) have vrange() return a
Re: [RFC][PATCH] mm: sl[uo]b: fix misleading comments
On Tue, 28 Jan 2014, Dave Hansen wrote: > From: Dave Hansen > > On x86, SLUB creates and handles <=8192-byte allocations internally. > It passes larger ones up to the allocator. Saying "up to order 2" is, > at best, ambiguous. Is that order-1? Or (order-2 bytes)? Make > it more clear. > > SLOB commits a similar sin. It *handles* page-size requests, but the > comment says that it passes up "all page size and larger requests". > > SLOB also swaps around the order of the very-similarly-named > KMALLOC_SHIFT_HIGH and KMALLOC_SHIFT_MAX #defines. Make it > consistent with the order of the other two allocators. > > Signed-off-by: Dave Hansen Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Do we really need curr_target in signal_struct ?
On Wed, Jan 29, 2014 at 10:09 AM, Rakib Mullick wrote: > On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov wrote: >> On 01/28, Rakib Mullick wrote: >> >> You could simply do while_each_thread(p, t) to find a thread which >> wants_signal(..). >> > Yes, while_each_thread() is much nicer than get_nr_thread(), thanks for > the pointer. > Or, should we use for_each_thread()? Just noticed that, you've plan to remove while_each_thread(). Thanks, Rakib -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc/iommu: Fix initialisation of DART iommu table
Commit d084775738b746648d4102337163a04534a02982 switched the generic powerpc iommu backend code to use the it_page_shift field to determine page size. Commit 3a553170d35d69bea3877bffa508489dfa6f133d should have initiliased this field for all platforms, however the DART iommu table code was not updated. This commit initialises the it_page_shift field to 4K for the DART iommu. Signed-off-by: Alistair Popple --- arch/powerpc/sysdev/dart_iommu.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c index bd968a4..62c47bb 100644 --- a/arch/powerpc/sysdev/dart_iommu.c +++ b/arch/powerpc/sysdev/dart_iommu.c @@ -292,6 +292,7 @@ static void iommu_table_dart_setup(void) iommu_table_dart.it_offset = 0; /* it_size is in number of entries */ iommu_table_dart.it_size = dart_tablesize / sizeof(u32); + iommu_table_dart.it_page_shift = IOMMU_PAGE_SHIFT_4K; /* Initialize the common IOMMU code */ iommu_table_dart.it_base = (unsigned long)dart_vbase; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] devres: introduce API "devm_kstrdup"
On Wed, 2014-01-29 at 09:33 +0530, Manish Badarkhe wrote:
> This patch introduces "devm_kstrdup" API so that the
> device's driver can allocate memory and copy string.
[]
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
[]
> @@ -791,6 +791,32 @@ void * devm_kmalloc(struct device *dev, size_t size,
> gfp_t gfp)
> EXPORT_SYMBOL_GPL(devm_kmalloc);
>
> /**
> + * devm_kstrdup - Allocate resource managed space and
> + *and copy an existing string
> + * @dev: Device to allocate memory for
> + * @s: the string to duplicate
> + * @size: Allocation size
Why is size necessary at all?
I think it should be calculated by strlen
> +char *devm_kstrdup(struct device *dev,
> +const char *s, size_t size, gfp_t gfp)
> +{
> + char *buf;
> +
> + if (!s)
> + return NULL;
> +
> + buf = devm_kzalloc(dev, size, gfp);
If this is really necessary, please use devm_kmalloc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] cgroup: drop module support
> /**
> - * for_each_subsys - iterate all loaded cgroup subsystems
> + * for_each_subsys - iterate all enabled cgroup subsystems
> * @ss: the iteration cursor
> * @ssid: the index of @ss, CGROUP_SUBSYS_COUNT after reaching the end
> - *
> - * Iterates through all loaded subsystems. Should be called under
> - * cgroup_mutex or cgroup_root_mutex.
> */
> #define for_each_subsys(ss, ssid)\
> - for (({ cgroup_assert_mutex_or_root_locked(); (ssid) = 0; }); \
> - (ssid) < CGROUP_SUBSYS_COUNT; (ssid)++)\
> - if (!((ss) = cgroup_subsys[(ssid)])) { }\
> - else
> -
> -/**
> - * for_each_builtin_subsys - iterate all built-in cgroup subsystems
> - * @ss: the iteration cursor
> - * @i: the index of @ss, CGROUP_BUILTIN_SUBSYS_COUNT after reaching the end
> - *
> - * Bulit-in subsystems are always present and iteration itself doesn't
> - * require any synchronization.
> - */
> -#define for_each_builtin_subsys(ss, i)
> \
> - for ((i) = 0; (i) < CGROUP_BUILTIN_SUBSYS_COUNT && \
> - (((ss) = cgroup_subsys[i]) || true); (i)++)
> + for ((ssid) = 0; (ssid) < CGROUP_SUBSYS_COUNT &&\
> + (((ss) = cgroup_subsys[ssid]) || true); (ssid)++)
Now cgroup_subsys[i] won't be NULL, so we can drop "|| true".
>
> /* iterate across the active hierarchies */
> #define for_each_active_root(root) \
> @@ -975,50 +951,24 @@ static void cgroup_d_remove_dir(struct dentry *dentry)
> remove_dir(dentry);
> }
>
...
> - if (need_forkexit_callback) {
> - /*
> - * fork/exit callbacks are supported only for builtin
> - * subsystems, and the builtin section of the subsys
> - * array is immutable, so we don't need to lock the
> - * subsys array here. On the other hand, modular section
> - * of the array can be freed at module unload, so we
> - * can't touch that.
> - */
> - for_each_builtin_subsys(ss, i)
> + if (need_forkexit_callback)
> + for_each_subsys(ss, i)
> if (ss->fork)
> ss->fork(child);
> - }
This looks a bit ugly. How about leaving the parentheses for the
outmost if statement?
if (need_forkexit_callback) {
for_each_subsys(ss, i)
if (ss->fork)
ss->fork(child);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Do we really need curr_target in signal_struct ?
On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov wrote: > On 01/28, Rakib Mullick wrote: > > You could simply do while_each_thread(p, t) to find a thread which > wants_signal(..). > Yes, while_each_thread() is much nicer than get_nr_thread(), thanks for the pointer. > But I guess ->curr_target was added exactly to avoid this loop if > possible, assuming that wants_signal(->current_targer) should be > likely true. Although perhaps this optimization is too simple. > Well, this code block will only hit when first check for wants_signal() will miss, that means we need to find some other thread of the group. AFAIU, ->current_target is only a loop breaker to avoid infinite loop, but - by using while_each_thread() we can remove it completely, thus helps to get rid from maintaining it too. I'll prepare a proper patch with you suggestions for reviewing. Thanks, Rakib -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/2] devm_* API operation for fixed regulator
Use devm_* API operations for fixed regulator driver so that driver core will manage resources. Also, introduce a new API "devm_kstrdup" and used it in fixed regulator driver to manage resources. Changes since V2: 1. Update driver to use new API "devm_kstrdup" instead of "kstrdup". 2. Added a seperate patch to introduce new API "devm_kstrdup" Changes since V1: 1. Updated driver to use "devm_kzalloc" instead of "kstrdup". 2. Updated commit message. Manish Badarkhe (2): devres: introduce API "devm_kstrdup" regulator: fixed: update to devm_* API drivers/base/devres.c | 26 ++ drivers/regulator/fixed.c | 44 ++-- include/linux/device.h|2 ++ 3 files changed, 42 insertions(+), 30 deletions(-) -- 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/
[PATCH V3 1/2] devres: introduce API "devm_kstrdup"
This patch introduces "devm_kstrdup" API so that the
device's driver can allocate memory and copy string.
Signed-off-by: Manish Badarkhe
---
:100644 100644 545c4de... 6e88a3d... M drivers/base/devres.c
:100644 100644 952b010... 8fee649... M include/linux/device.h
drivers/base/devres.c | 26 ++
include/linux/device.h |2 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 545c4de..6e88a3d 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -791,6 +791,32 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t
gfp)
EXPORT_SYMBOL_GPL(devm_kmalloc);
/**
+ * devm_kstrdup - Allocate resource managed space and
+ *and copy an existing string
+ * @dev: Device to allocate memory for
+ * @s: the string to duplicate
+ * @size: Allocation size
+ * @gfp: the GFP mask used in the devm_kzalloc() call when
+ * allocating memory
+ * RETURNS:
+ * Pointer to allocated string on success, NULL on failure.
+ */
+char *devm_kstrdup(struct device *dev,
+ const char *s, size_t size, gfp_t gfp)
+{
+ char *buf;
+
+ if (!s)
+ return NULL;
+
+ buf = devm_kzalloc(dev, size, gfp);
+ if (buf)
+ memcpy(buf, s, size);
+ return buf;
+}
+EXPORT_SYMBOL_GPL(devm_kstrdup);
+
+/**
* devm_kfree - Resource-managed kfree
* @dev: Device this memory belongs to
* @p: Memory to free
diff --git a/include/linux/device.h b/include/linux/device.h
index 952b010..8fee649 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -626,6 +626,8 @@ static inline void *devm_kcalloc(struct device *dev,
return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
}
extern void devm_kfree(struct device *dev, void *p);
+extern char *devm_kstrdup(struct device *dev, const char *s, size_t size,
+ gfp_t gfp);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
void __iomem *devm_request_and_ioremap(struct device *dev,
--
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/
[PATCH V3 2/2] regulator: fixed: update to devm_* API
Update the code to use devm_* API so that driver core will manage
resources.
Signed-off-by: Manish Badarkhe
---
:100644 100644 5ea64b9... 1d42613... M drivers/regulator/fixed.c
drivers/regulator/fixed.c | 44 ++--
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 5ea64b9..1d42613 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -132,15 +132,16 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
GFP_KERNEL);
if (drvdata == NULL) {
dev_err(>dev, "Failed to allocate device data\n");
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
- drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
+ drvdata->desc.name = devm_kstrdup(>dev,
+ config->supply_name,
+ strlen(config->supply_name) + 1,
+ GFP_KERNEL);
if (drvdata->desc.name == NULL) {
dev_err(>dev, "Failed to allocate supply name\n");
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
drvdata->desc.type = REGULATOR_VOLTAGE;
drvdata->desc.owner = THIS_MODULE;
@@ -149,13 +150,14 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
drvdata->desc.enable_time = config->startup_delay;
if (config->input_supply) {
- drvdata->desc.supply_name = kstrdup(config->input_supply,
- GFP_KERNEL);
+ drvdata->desc.supply_name = devm_kstrdup(>dev,
+ config->input_supply,
+ strlen(config->input_supply) + 1,
+ GFP_KERNEL);
if (!drvdata->desc.supply_name) {
dev_err(>dev,
"Failed to allocate input supply\n");
- ret = -ENOMEM;
- goto err_name;
+ return -ENOMEM;
}
}
@@ -186,11 +188,12 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
cfg.driver_data = drvdata;
cfg.of_node = pdev->dev.of_node;
- drvdata->dev = regulator_register(>desc, );
+ drvdata->dev = devm_regulator_register(>dev, >desc,
+ );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
dev_err(>dev, "Failed to register regulator: %d\n", ret);
- goto err_input;
+ return ret;
}
platform_set_drvdata(pdev, drvdata);
@@ -199,24 +202,6 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
drvdata->desc.fixed_uV);
return 0;
-
-err_input:
- kfree(drvdata->desc.supply_name);
-err_name:
- kfree(drvdata->desc.name);
-err:
- return ret;
-}
-
-static int reg_fixed_voltage_remove(struct platform_device *pdev)
-{
- struct fixed_voltage_data *drvdata = platform_get_drvdata(pdev);
-
- regulator_unregister(drvdata->dev);
- kfree(drvdata->desc.supply_name);
- kfree(drvdata->desc.name);
-
- return 0;
}
#if defined(CONFIG_OF)
@@ -229,7 +214,6 @@ MODULE_DEVICE_TABLE(of, fixed_of_match);
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
- .remove = reg_fixed_voltage_remove,
.driver = {
.name = "reg-fixed-voltage",
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: move the one-off opts sanity check in cgroup_root_from_opts() to parse_cgroupfs_options()
On 2014/1/28 23:32, Tejun Heo wrote: > cgroup_root_from_opts() checks whether (!opts->subsys_mask && > !opts->none) and returns NULL if so. After that, if allocation fails, > returns ERR_PTR(-ENOMEM). The caller, cgroup_mount(), doesn't treat > NULL as an error but set opts.new_root to NULL; however, later on, > cgroup_set_super() fails with -EINVAL if new_root is NULL. This patch changes mount semantics. If cgroup_root_from_opts() returns NULL, it means we should be looking for existing superblock only. This will fail: # mount -t cgroup -o name=abc xxx /mnt But this is ok: # mount -t cgroup -o none,name=abc xxx /mnt # mkdir /mnt/sub # umount /mnt # mount -t cgroup -o name=abc xxx /mnt <-- this won't work with your patch > > This is one bizarre error handling sequence especially when all other > opts sanity checks including the very close (!opts->subsys_mask && > !opts->name) check are done in parse_cgroupfs_options(). > > Let's move the one-off check in cgroup_root_from_opts() to > parse_cgroupfs_options() where it can be combined with the > (!opts->subsys_mask && !opts->name) check. cgroup_root_from_opts() is > updated to return NULL on memory allocation failure. > > Signed-off-by: Tejun Heo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
Hi, On Mon, Jan 27, 2014 at 10:24 PM, Maxime Ripard wrote: > Hi, > > On Fri, Jan 17, 2014 at 02:47:29PM +0800, Chen-Yu Tsai wrote: >> Signed-off-by: Chen-Yu Tsai >> --- >> .../devicetree/bindings/rfkill/rfkill-gpio.txt | 26 >> ++ >> net/rfkill/rfkill-gpio.c | 23 +++ >> 2 files changed, 49 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> >> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> new file mode 100644 >> index 000..8a07ea4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> @@ -0,0 +1,26 @@ >> +GPIO controlled RFKILL devices >> + >> +Required properties: >> +- compatible : Must be "rfkill-gpio". >> +- rfkill-name: Name of RFKILL device >> +- rfkill-type: Type of RFKILL device: 1 for WiFi, 2 for BlueTooth >> +- NAME_shutdown-gpios: GPIO phandle to shutdown control >> + (phandle must be the second) > > Can't it be handled by a regulator? > >> +- NAME_reset-gpios : GPIO phandle to reset control > > And this one using the reset framework? The driver is already used in platform device and ACPI fashions. AFAIK, ACPI only passes the GPIO lines. Preferably the behavior and requirements between the different usages remain the same. Cheers ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: compile error on linus git with ppc64
On Tue, 28 Jan 2014, Jesse Brandeburg wrote:
> fresh pull, commit d891ea23d5203e5c47439b2a174f86a00b356a6c - merge
> ceph-client.
>
> I get a compile error:
> jbrandeb@jbrandeb-pseries:~/git/linux> make -j12
> scripts/kconfig/conf --silentoldconfig Kconfig
> CHK include/config/kernel.release
> WRAParch/powerpc/include/generated/asm/clkdev.h
> WRAParch/powerpc/include/generated/asm/rwsem.h
> WRAParch/powerpc/include/generated/asm/trace_clock.h
> WRAParch/powerpc/include/generated/asm/preempt.h
> WRAParch/powerpc/include/generated/asm/hash.h
> WRAParch/powerpc/include/generated/asm/vtime.h
> CHK include/generated/uapi/linux/version.h
> UPD include/generated/uapi/linux/version.h
> HOSTCC scripts/dtc/checks.o
> HOSTCC scripts/dtc/data.o
> SHIPPED scripts/dtc/dtc-lexer.lex.c
> SHIPPED scripts/dtc/dtc-parser.tab.h
> HOSTCC scripts/kallsyms
> HOSTCC scripts/genksyms/genksyms.o
> CC scripts/mod/empty.o
> HOSTCC scripts/mod/mk_elfconfig
> CC scripts/mod/devicetable-offsets.s
> SHIPPED scripts/dtc/dtc-parser.tab.c
> HOSTCC scripts/dtc/dtc.o
> SHIPPED scripts/genksyms/lex.lex.c
> SHIPPED scripts/genksyms/keywords.hash.c
> HOSTCC scripts/pnmtologo
> SHIPPED scripts/genksyms/parse.tab.h
> SHIPPED scripts/genksyms/parse.tab.c
> HOSTCC scripts/dtc/flattree.o
> HOSTCC scripts/dtc/fstree.o
> HOSTCC scripts/genksyms/lex.lex.o
> HOSTCC scripts/genksyms/parse.tab.o
> HOSTCC scripts/dtc/livetree.o
> HOSTCC scripts/dtc/srcpos.o
> HOSTCC scripts/dtc/treesource.o
> HOSTCC scripts/conmakehash
> HOSTCC scripts/bin2c
> MKELF scripts/mod/elfconfig.h
> HOSTCC scripts/dtc/util.o
> HOSTCC scripts/mod/modpost.o
> HOSTCC scripts/mod/sumversion.o
> HOSTCC scripts/dtc/dtc-lexer.lex.o
> HOSTLD scripts/genksyms/genksyms
> HOSTCC scripts/dtc/dtc-parser.tab.o
> GEN scripts/mod/devicetable-offsets.h
> HOSTCC scripts/mod/file2alias.o
> HOSTLD scripts/dtc/dtc
> HOSTLD scripts/mod/modpost
> UPD include/config/kernel.release
> CHK include/generated/utsrelease.h
> UPD include/generated/utsrelease.h
> CC kernel/bounds.s
> GEN include/generated/bounds.h
> CC arch/powerpc/kernel/asm-offsets.s
> In file included from include/linux/spinlock.h:81,
> from include/linux/seqlock.h:35,
> from include/linux/time.h:5,
> from include/uapi/linux/timex.h:56,
> from include/linux/timex.h:56,
> from include/linux/sched.h:17,
> from arch/powerpc/kernel/asm-offsets.c:17:
> include/linux/spinlock_types.h:76: error: redefinition of typedef
> ‘spinlock_t’
> /home/jbrandeb/git/linux/arch/powerpc/include/asm/pgtable-ppc64.h:563:
> error: previous declaration of ‘spinlock_t’ was here
Confirmed, I saw this with ppc64_defconfig. It's due to b3084f4db3ae
("powerpc/thp: Fix crash on mremap").
powerpc, spinlock: fix build error
Build fails with
include/linux/spinlock_types.h:76: error: redefinition of typedef ‘spinlock_t’
arch/powerpc/include/asm/pgtable-ppc64.h:563: error: previous declaration of
‘spinlock_t’ was here
due to commit b3084f4db3ae ("powerpc/thp: Fix crash on mremap"). Remove
the bogus typedef and include spinlock_types.h.
Reported-by: Jesse Brandeburg
Signed-off-by: David Rientjes
---
arch/powerpc/include/asm/pgtable-ppc64.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -365,6 +365,8 @@ void pgtable_cache_init(void);
_PAGE_THP_HUGE)
#ifndef __ASSEMBLY__
+#include
+
/*
* The linux hugepage PMD now include the pmd entries followed by the address
* to the stashed pgtable_t. The stashed pgtable_t contains the hpte bits.
@@ -560,7 +562,6 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,
unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
spinlock_t *old_pmd_ptl)
{
Re: [GIT PULL] clk: changes for 3.14, part 2
On Tue, Jan 28, 2014 at 6:44 PM, Linus Torvalds wrote: > On Mon, Jan 27, 2014 at 1:43 PM, Mike Turquette wrote: >> >> git://git.linaro.org/people/mike.turquette/linux.git >> tags/clk-for-linus-3.14-part2 > > Dammit, this is pure shit, and after having to deal with yet another > pointless merge conflict due to stupid "cleanups" in Makefiles, IT > DOES NOT EVEN COMPILE. > > drivers/clk/clk-si5351.c: In function 'si5351_i2c_probe': > drivers/clk/clk-si5351.c:1314:2: error: too many arguments to function > 'si5351_dt_parse' > ret = si5351_dt_parse(client, variant); > ^ > drivers/clk/clk-si5351.c:1296:12: note: declared here > static int si5351_dt_parse(struct i2c_client *client) > > And no, that's not due to a merge error of mine. It was that way in your tree. > > Hulk angry. Hulk smash. My apologies for making you hulk out. I did sneak some stuff in at the end and it bit us in the ass. Thank you for fixing it up. > > I fixed it up in the merge, but I shouldn't need to. This should have > been caught in -next, and even if you compile for ARM as your primary > target, I know *damn* well that no sane ARM developer actually > compiles *on* ARM (because there are no machines where it's worth the > pain), so you should make sure that the x86-64 build works too. > > If I can find compile errors within a couple of minutes of pulling and > it's not a merge error of mine, the tree I'm pulling from is clearly > crap. > > So I'm more than a bit grumpy. Get your act together, and don't send > me any more shit. > > In fact, I would suggest you send nothing but obvious fixes from now > on in this release. Because I won't be taking anything else. I only send fixes for actual regressions after -rc1. Additionally this weird two-part pull request was an anomaly and I don't plan to do it again. Again thanks for your patience, Mike > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the imx-mxs tree with the arm tree
On Wed, Jan 29, 2014 at 01:25:13PM +1100, Stephen Rothwell wrote: > Hi Shawn, > > On Wed, 29 Jan 2014 09:18:06 +0800 Shawn Guo wrote: > > > > I will rebase my branch on v3.14-rc1 once it's out. > > Um, does that mean that all that stuff is *not* destined for v3.14? ... Yes, Stephen. That's the case. If it causes problem for you, you can keep excluding my for-next branch from linux-next until I rebase it on v3.14-rc1. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/afs/proc.c between commit b42d570c9fbe ("afs: get rid of junk in
fs/afs/proc.c") from Linus' tree and commit 1a3459681f5c ("afs: proc
cells and rootcell are writeable") from the akpm-current 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 fs/afs/proc.c
index bddc5120ed40,276cb6ed0b93..
--- a/fs/afs/proc.c
+++ b/fs/afs/proc.c
@@@ -130,9 -147,13 +130,9 @@@ int afs_proc_init(void
if (!proc_afs)
goto error_dir;
- if (!proc_create("cells", 0, proc_afs, _proc_cells_fops) ||
- !proc_create("rootcell", 0, proc_afs, _proc_rootcell_fops))
- p = proc_create("cells", S_IFREG | S_IRUGO | S_IWUSR, proc_afs,
_proc_cells_fops);
- if (!p)
- goto error_cells;
-
- p = proc_create("rootcell", S_IFREG | S_IRUGO | S_IWUSR, proc_afs,
_proc_rootcell_fops);
- if (!p)
- goto error_rootcell;
++ if (!proc_create("cells", S_IFREG | S_IRUGO | S_IWUSR, proc_afs,
_proc_cells_fops) ||
++ !proc_create("rootcell", S_IFREG | S_IRUGO | S_IWUSR, proc_afs,
_proc_rootcell_fops))
+ goto error_tree;
_leave(" = 0");
return 0;
pgpGgBgU8u0Ry.pgp
Description: PGP signature
Re: [PATCH 3/3] net: via-rhine: add OF bus binding
On 29/01/14 07:27, Alexey Charkov wrote: 2014/1/27 Rob Herring : On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov wrote: This should make the driver usable with VIA/WonderMedia ARM-based Systems-on-Chip integrated Rhine III adapters. Note that these are always in MMIO mode, and don't have any known EEPROM. Signed-off-by: Alexey Charkov Signed-off-by: Roger Luethi --- .../devicetree/bindings/net/via-rhine.txt | 18 ++ drivers/net/ethernet/via/Kconfig | 2 +- drivers/net/ethernet/via/via-rhine.c | 293 + 3 files changed, 200 insertions(+), 113 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt new file mode 100644 index 000..684dd3a --- /dev/null +++ b/Documentation/devicetree/bindings/net/via-rhine.txt @@ -0,0 +1,18 @@ +* VIA Rhine 10/100 Network Controller + +Required properties: +- compatible : Should be "via,rhine" This should be more specific rather than... +- reg : Address and length of the io space +- interrupts : Should contain the controller interrupt line +- rhine,revision : Rhine core revision, used to inform the + driver of quirks and capabilities to expect from + the device. Mimics the respective PCI attribute. having this property. The OF match table can then have the quirks set based on compatible strings. Sounds fair. Do you think something like the following would fly? Required properties: - compatible : Should be "via,rhine-soc-vt8500" for integrated Rhine cores found in SoC's such as VIA VT8500, WonderMedia WM8950 and possibly others. These are listed as 1106:3106 rev. 0x84 on the virtual PCI bus under vendor-provided kernels. Does it need a special name? I would have assumed they are using their own IP for the VT6105 or VT6106S. Then you can use it to add quirks later on if needed. Regards Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] cgroup: fix locking in cgroup_cfts_commit()
On 2014/1/28 23:32, Tejun Heo wrote: > cgroup_cfts_commit() walks the cgroup hierarchy that the target > subsystem is attached to and tries to apply the file changes. Due to > the convolution with inode locking, it can't keep cgroup_mutex locked > while iterating. It currently holds only RCU read lock around the > actual iteration and then pins the found cgroup using dget(). > > Unfortunately, this is incorrect. Although the iteration does check > cgroup_is_dead() before invoking dget(), there's nothing which > prevents the dentry from going away inbetween. Note that this is > different from the usual css iterations where css_tryget() is used to > pin the css - css_tryget() tests whether the css can be pinned and > fails if not. > > The problem can be solved by simply holding cgroup_mutex instead of > RCU read lock around the iteration, which actually reduces LOC. > > Signed-off-by: Tejun Heo > Cc: sta...@vger.kernel.org Good catch! Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] cgroup: fix error return value in cgroup_mount()
On 2014/1/28 23:32, Tejun Heo wrote: > When cgroup_mount() fails to allocate an id for the root, it didn't > set ret before jumping to unlock_drop ending up returning 0 after a > failure. Fix it. > > Signed-off-by: Tejun Heo > Cc: sta...@vger.kernel.org Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] cgroup: fix error return from cgroup_create()
On 2014/1/28 23:32, Tejun Heo wrote: > cgroup_create() was returning 0 after allocation failures. Fix it. > > Signed-off-by: Tejun Heo > Cc: sta...@vger.kernel.org Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 clk tree
Hi Mike,
After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/clk/clk-si5351.c: In function 'si5351_i2c_probe':
drivers/clk/clk-si5351.c:1314:2: error: too many arguments to function
'si5351_dt_parse'
ret = si5351_dt_parse(client, variant);
^
drivers/clk/clk-si5351.c:1296:12: note: declared here
static int si5351_dt_parse(struct i2c_client *client)
^
Caused by commit 9d43dc7f403d ("clk: si5351: remove variant from
platform_data").
I have used the clk tree from next-20140128 for today. (Yes, I know that
Linus already took this - I guess I won't have to worry about it
tomorrow.)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgphhMjttBQrq.pgp
Description: PGP signature
linux-next: manual merge of the clk tree with Linus' tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
drivers/clk/Makefile between commit 0ad6125b1579 ("clk: at91: add PMC
base support") from Linus' tree and commit fd3fdaf09f26 ("clk: sort
Makefile") from the clk 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/clk/Makefile
index a277875d64a7,51a4c0dac1af..
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -9,46 -9,43 +9,44 @@@ obj-$(CONFIG_COMMON_CLK) += clk-gate.
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
- # SoCs specific
- obj-$(CONFIG_ARCH_BCM2835)+= clk-bcm2835.o
- obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
- obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
- obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
- obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
- obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
- obj-$(CONFIG_ARCH_MXS)+= mxs/
- obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/
- obj-$(CONFIG_PLAT_SPEAR) += spear/
- obj-$(CONFIG_ARCH_U300) += clk-u300.o
- obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
- obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
- obj-$(CONFIG_PLAT_ORION) += mvebu/
+ # hardware specific clock types
+ # please keep this section sorted lexicographically by file/directory path
name
++obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
+ obj-$(CONFIG_ARCH_BCM2835)+= clk-bcm2835.o
+ obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+ obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
+ obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
+ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+ obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
+ obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+ obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+ obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
+ obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+ obj-$(CONFIG_COMMON_CLK_SI570)+= clk-si570.o
+ obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
+ obj-$(CONFIG_ARCH_U300) += clk-u300.o
+ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
+ obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
+ obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
+ obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
+ obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
ifeq ($(CONFIG_COMMON_CLK), y)
- obj-$(CONFIG_ARCH_MMP)+= mmp/
+ obj-$(CONFIG_ARCH_MMP)+= mmp/
endif
- obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
- obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
- obj-$(CONFIG_ARCH_SUNXI) += sunxi/
- obj-$(CONFIG_ARCH_U8500) += ux500/
- obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
- obj-$(CONFIG_ARCH_SIRF) += sirf/
- obj-$(CONFIG_ARCH_ZYNQ) += zynq/
- obj-$(CONFIG_ARCH_TEGRA) += tegra/
- obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
- obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
- obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
- obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+ obj-$(CONFIG_PLAT_ORION) += mvebu/
+ obj-$(CONFIG_ARCH_MXS)+= mxs/
+ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
+ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
+ obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
-
- obj-$(CONFIG_X86) += x86/
- obj-$(CONFIG_ARCH_BCM)+= bcm/
-
- # Chip specific
- obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
- obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
- obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
- obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
- obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
- obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
- obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
- obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+ obj-$(CONFIG_ARCH_SIRF) += sirf/
+ obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/
+ obj-$(CONFIG_PLAT_SPEAR) += spear/
+ obj-$(CONFIG_ARCH_SUNXI) += sunxi/
+ obj-$(CONFIG_ARCH_TEGRA) += tegra/
+ obj-$(CONFIG_ARCH_OMAP2PLUS) += ti/
+ obj-$(CONFIG_ARCH_U8500) += ux500/
+ obj-$(CONFIG_COMMON_CLK_VERSATILE)+= versatile/
+ obj-$(CONFIG_X86) += x86/
+ obj-$(CONFIG_ARCH_ZYNQ) += zynq/
pgp8jq0GYXTpE.pgp
Description: PGP signature
Re: [git pull] vfs pile 1
On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote: > Assorted stuff; the biggest pile here is Christoph's ACL series. > Plus assorted cleanups and fixes all over the place... There will be > another pile later this week. The posix_acl_chmod() code looks wrong. Not that it looked right before either, but whatever. The code basically looks like some variation of this in most setattr() implementations: if (ia_valid & ATTR_MODE) rc = posix_acl_chmod(inode, inode->i_mode); but the mode we're changing to (and what ATTR_MODE guards) is actually attr->ia_mode, not inode->i_mode. And quite frankly, passing in inode->i_mode looks stupid, since we're already passing in the inode pointer, so that's just redundant and pointless information. Anyway, I noticed this after doing the (untested, and still un-acked - hint, hint) ceph conversion. In that, I made ceph use attr->ia_mode. Maybe that was wrong, but at least it's not insane and stupid like the other filesystem implementations are. Comments? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu wrote: > Sander Eikelenboom : > [...] >> I have got a regression with a 3.14-mw kernel (last commit is >> 4ba9920e5e9c0e16b5ed24292d45322907bb9035): >> It looks like it's related to the rtl8169 ... >> >> -- >> Sander >> >> Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here >> ] >> Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 >> at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() >> Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 >> overlapping mappings of pfn 55ebe >> Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: >> Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: >> swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI >> MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 >> 88005f603838 81acbcfa 822134e0 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 >> 88005f603878 810bdf62 8800 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe >> ffef 0200 8800592ea098 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: >> Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] >> [] dump_stack+0x46/0x58 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [] >> warn_slowpath_common+0x82/0xb0 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [] >> warn_slowpath_fmt+0x41/0x50 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [] >> ? active_pfn_read_overlap+0x3a/0x70 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [] >> add_dma_entry+0x103/0x130 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [] >> debug_dma_map_page+0x126/0x150 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [] >> rtl8169_start_xmit+0x216/0xa20 > [r8169 and xen stuff] > > Dan, I miss the part of the debug code that tells where the mappings were > previously set. In this case it was a facepalm mistake on my part. The mappings were not being properly accounted in the last revision of the patch I sent. I copied you on the fix [1]. -- Dan [1]: http://marc.info/?l=linux-netdev=139096447627032=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 regression] dma-debug: fix overlap detection
Commit 0abdd7a81b7e "dma-debug: introduce debug_dma_assert_idle()" was reworked to expand the overlap counter to the full range expressable by 3 tag bits, but it has a thinko in treating the overlap counter as a pure reference count for the entry. Instead of deleting when the reference-count drops to zero, we need to delete when the overlap-count drops below zero. Also, when detecting overflow we can just test the overlap-count > MAX rather than applying special meaning to 0. Cc: Francois Romieu Reported-by: Sander Eikelenboom Signed-off-by: Dan Williams --- Regression report available here: http://marc.info/?l=linux-netdev=139073373932386=2 This patch, now tested on the original net_dma case, sees the expected handful of reports before the eventual data corruption occurs. lib/dma-debug.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/dma-debug.c b/lib/dma-debug.c index c38083871f11..2defd1308b04 100644 --- a/lib/dma-debug.c +++ b/lib/dma-debug.c @@ -463,7 +463,7 @@ static int active_pfn_set_overlap(unsigned long pfn, int overlap) int i; if (overlap > ACTIVE_PFN_MAX_OVERLAP || overlap < 0) - return 0; + return overlap; for (i = RADIX_TREE_MAX_TAGS - 1; i >= 0; i--) if (overlap & 1 << i) @@ -486,7 +486,7 @@ static void active_pfn_inc_overlap(unsigned long pfn) * debug_dma_assert_idle() as the pfn may be marked idle * prematurely. */ - WARN_ONCE(overlap == 0, + WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP, "DMA-API: exceeded %d overlapping mappings of pfn %lx\n", ACTIVE_PFN_MAX_OVERLAP, pfn); } @@ -517,7 +517,11 @@ static void active_pfn_remove(struct dma_debug_entry *entry) unsigned long flags; spin_lock_irqsave(_lock, flags); - if (active_pfn_dec_overlap(entry->pfn) == 0) + /* since we are counting overlaps the final put of the +* entry->pfn will occur when the overlap count is 0. +* active_pfn_dec_overlap() returns -1 in that case +*/ + if (active_pfn_dec_overlap(entry->pfn) < 0) radix_tree_delete(_active_pfn, entry->pfn); spin_unlock_irqrestore(_lock, flags); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
> So the 1-2 threads case is the standard case on a small > system, isn't it? This may well cause regressions. Well, the common case should be uncontended, which is faster. But yes, testing would be nice. >> In the extremely unlikely case that all the queue node entries are >> used up, the current code will fall back to busy spinning without >> waiting in a queue with warning message. > Traditionally we had some code which could take thousands > of locks in rare cases (e.g. all locks in a hash table or all locks of > a big reader lock) Doesn't apply; the question implies a misunderstanding of what's happening. The entry is only needed while spinning waiting for the lock. Once the lock has been acquired, it may be recycled. The thread may *hold* thousands of locks; the entries only apply to locks being *waited for*. >From process context a thread may only be waiting for one at a time. Additional entries are only needed in case a processor takes an interrupt while spinning, and the interrupt handler wants to take a lock, too. If that lock also has to be waited for, and during the wait you take a nested interrupt or NMI, a third level might happen. The chances of this being nested more than 4 deep seem sufficiently minute. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] clk: changes for 3.14, part 2
On Tue, 28 Jan 2014 18:44:31 -0800 Linus Torvalds wrote: > > On Mon, Jan 27, 2014 at 1:43 PM, Mike Turquette wrote: > > > > git://git.linaro.org/people/mike.turquette/linux.git > > tags/clk-for-linus-3.14-part2 > > I fixed it up in the merge, but I shouldn't need to. This should have > been caught in -next, and even if you compile for ARM as your primary Yes, it probably will be when I get to that tree today as those last 6 commits only hit here today. :-( -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp_c1LL3ijjm.pgp Description: PGP signature
Re: [GIT PULL] clk: changes for 3.14, part 2
On Mon, Jan 27, 2014 at 1:43 PM, Mike Turquette wrote: > > git://git.linaro.org/people/mike.turquette/linux.git > tags/clk-for-linus-3.14-part2 Dammit, this is pure shit, and after having to deal with yet another pointless merge conflict due to stupid "cleanups" in Makefiles, IT DOES NOT EVEN COMPILE. drivers/clk/clk-si5351.c: In function ‘si5351_i2c_probe’: drivers/clk/clk-si5351.c:1314:2: error: too many arguments to function ‘si5351_dt_parse’ ret = si5351_dt_parse(client, variant); ^ drivers/clk/clk-si5351.c:1296:12: note: declared here static int si5351_dt_parse(struct i2c_client *client) And no, that's not due to a merge error of mine. It was that way in your tree. Hulk angry. Hulk smash. I fixed it up in the merge, but I shouldn't need to. This should have been caught in -next, and even if you compile for ARM as your primary target, I know *damn* well that no sane ARM developer actually compiles *on* ARM (because there are no machines where it's worth the pain), so you should make sure that the x86-64 build works too. If I can find compile errors within a couple of minutes of pulling and it's not a merge error of mine, the tree I'm pulling from is clearly crap. So I'm more than a bit grumpy. Get your act together, and don't send me any more shit. In fact, I would suggest you send nothing but obvious fixes from now on in this release. Because I won't be taking anything else. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
Tom Gundersen writes:
> Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
> second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
> the modaliases being exposed.
>
> This fixes the problem by including the name of the device_id table in the
> __mod_*_device_table alias, allowing us to export several device_id tables
> per module.
Thanks, applied.
I also put this on top:
module: remove MODULE_GENERIC_TABLE
MODULE_DEVICE_TABLE() calles MODULE_GENERIC_TABLE(); make it do the
work directly. This also removes a wart introduced in the last patch,
where the alias is defined to be an unknown struct type "struct
type##__##name##_device_id" instead of "struct type##_device_id" (it's
an extern so GCC doesn't care, but it's wrong).
The other user of MODULE_GENERIC_TABLE (ISAPNP_CARD_TABLE) is unused,
so delete it.
Signed-off-by: Rusty Russell
diff --git a/include/linux/isapnp.h b/include/linux/isapnp.h
index e2d28b026a8c..3c77bf9b1efd 100644
--- a/include/linux/isapnp.h
+++ b/include/linux/isapnp.h
@@ -56,10 +56,6 @@
#define ISAPNP_DEVICE_ID(_va, _vb, _vc, _function) \
{ .vendor = ISAPNP_VENDOR(_va, _vb, _vc), .function =
ISAPNP_FUNCTION(_function) }
-/* export used IDs outside module */
-#define ISAPNP_CARD_TABLE(name) \
- MODULE_GENERIC_TABLE(isapnp_card, name)
-
struct isapnp_card_id {
unsigned long driver_data; /* data private to the driver */
unsigned short card_vendor, card_device;
diff --git a/include/linux/module.h b/include/linux/module.h
index ad18f6006f86..5686b37e11d6 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -82,15 +82,6 @@ void sort_extable(struct exception_table_entry *start,
void sort_main_extable(void);
void trim_init_extable(struct module *m);
-#ifdef MODULE
-#define MODULE_GENERIC_TABLE(gtype, name) \
-extern const struct gtype##_id __mod_##gtype##_table \
- __attribute__ ((unused, alias(__stringify(name
-
-#else /* !MODULE */
-#define MODULE_GENERIC_TABLE(gtype, name)
-#endif
-
/* Generic info of form tag = "info" */
#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
@@ -141,8 +132,14 @@ extern const struct gtype##_id __mod_##gtype##_table
\
/* What your module does. */
#define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
-#define MODULE_DEVICE_TABLE(type, name)\
- MODULE_GENERIC_TABLE(type##__##name##_device, name)
+#ifdef MODULE
+/* Creates an alias so file2alias.c can find device table. */
+#define MODULE_DEVICE_TABLE(type, name)
\
+ extern const struct type##_device_id __mod_##type##__##name##_device_table \
+ __attribute__ ((unused, alias(__stringify(name
+#else /* !MODULE */
+#define MODULE_DEVICE_TABLE(type, name)
+#endif
/* Version of form [:][-].
* Or for CVS/RCS ID version, everything but the number is stripped.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [V0 PATCH] pvh: Disable PSE feature for now
On Tue, 28 Jan 2014 10:39:23 + "Jan Beulich" wrote: > >>> On 28.01.14 at 03:18, Mukesh Rathor > >>> wrote: > > Until now, xen did not expose PSE to pvh guest, but a patch was > > submitted to xen list to enable bunch of features for a pvh guest. > > PSE has not been looked into for PVH, so until we can do that and > > test it to make sure it works, disable the feature to avoid flood > > of bugs. > > > > Signed-off-by: Mukesh Rathor > > --- > > arch/x86/xen/enlighten.c |5 + > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > > index a4d7b64..4e952046 100644 > > --- a/arch/x86/xen/enlighten.c > > +++ b/arch/x86/xen/enlighten.c > > @@ -1497,6 +1497,11 @@ static void __init > > xen_pvh_early_guest_init(void) xen_have_vector_callback = 1; > > xen_pvh_set_cr_flags(0); > > > > +/* pvh guests are not quite ready for large pages yet */ > > +setup_clear_cpu_cap(X86_FEATURE_PSE); > > +setup_clear_cpu_cap(X86_FEATURE_PSE36); > > And why would you not want to also turn of 1Gb pages then? Right, that should be turned off too, but Konrad thinks we should leave them on in linux and deal with issues as they come. I've not tested them, or looked/thought about them, so had thought would be better to turn them on after I/someone gets to test them. thanks Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [V0 PATCH] pvh: Disable PSE feature for now
On Mon, 27 Jan 2014 22:46:34 -0500 Konrad Rzeszutek Wilk wrote: > On Mon, Jan 27, 2014 at 06:18:39PM -0800, Mukesh Rathor wrote: > > Until now, xen did not expose PSE to pvh guest, but a patch was > > submitted to xen list to enable bunch of features for a pvh guest. > > PSE has not been > > Which 'patch'? > > > looked into for PVH, so until we can do that and test it to make > > sure it works, disable the feature to avoid flood of bugs. > > I think we want a flood of bugs, no? Ok, but lets document (via this email :)), that they are not tested. thanks Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/6] misc: fuse: Add efuse driver for Tegra
On Wed, 2014-01-29 at 07:36 +0800, Peter De Schrijver wrote: > Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124. > > Signed-off-by: Peter De Schrijver > --- > Documentation/ABI/testing/sysfs-driver-tegra-fuse |8 + > drivers/misc/fuse/Makefile|1 + > drivers/misc/fuse/tegra/Makefile |7 + > drivers/misc/fuse/tegra/fuse-tegra.c | 228 > drivers/misc/fuse/tegra/fuse-tegra20.c| 136 ++ > drivers/misc/fuse/tegra/fuse-tegra30.c| 178 + > drivers/misc/fuse/tegra/fuse.h| 82 ++ Could we move this fuse.h to other folder under /include/linux (like /include/linux/platform_data) for other driver to include? So other driver can invoke function to read fuse data if needed. --nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: manual merge of the imx-mxs tree with the arm tree
Hi Shawn, On Wed, 29 Jan 2014 09:18:06 +0800 Shawn Guo wrote: > > I will rebase my branch on v3.14-rc1 once it's out. Um, does that mean that all that stuff is *not* destined for v3.14? ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpngr0ewErs2.pgp Description: PGP signature
[PATCH] firmware: give a protection when map page failed
>From 9c23aedc1c1a1446dae96ffec8f20a2f52942281 Mon Sep 17 00:00:00 2001
From: jzha144
Date: Wed, 29 Jan 2014 09:57:05 +0800
Subject: [PATCH] firmware: give a protection when map page failed
[ 7341.474236] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive
unpin_work!
[ 7341.494464] atomisp-css2400b0_v21 :00:03.0: unhandled css stored event:
0x20
[ 7341.503627] vmap allocation for size 208896 failed: use vmalloc= to
increase size.<=== map failed
[ 7341.507135] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive
unpin_work!
[ 7341.503848] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 7341.520394] IP: [] sst_load_all_modules_elf+0x1bb/0x850
[ 7341.527216] *pdpt = 30dfe001 *pde =
[ 7341.533640] Oops: [#1] PREEMPT SMP
[ 7341.540360] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive
unpin_work!
[ 7341.538037] Modules linked in: atomisp_css2400b0_v21 lm3554 ov2722 imx1x5
atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm
hdmi_audio bcm4334x(O)
[ 7341.563531] CPU: 1 PID: 525 Comm: mediaserver Tainted: GW O
3.10.20-262518-ga83c053 #1
[ 7341.573253] task: f0994ec0 ti: f09f task.ti: f09f
[ 7341.579284] EIP: 0060:[] EFLAGS: 00010246 CPU: 1
[ 7341.585415] EIP is at sst_load_all_modules_elf+0x1bb/0x850
[ 7341.591541] EAX: EBX: e3595ba0 ECX: EDX: 00031c1c
[ 7341.598541] ESI: e04a EDI: EBP: f09f1d80 ESP: f09f1cf4
[ 7341.605542] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
[ 7341.611573] CR0: 80050033 CR2: CR3: 30db4000 CR4: 001007f0
[ 7341.618573] DR0: DR1: DR2: DR3:
[ 7341.625575] DR6: 0ff0 DR7: 0400
[ 7341.629856] Stack:
[ 7341.632097] f09f1d57 0019 c1d656d7 c1d658d3 c1d56409 0f28 c1d64af9
18000103
[ 7341.640766] 0101 0008 c1f910a0 f326f4c8 0034 f326f520 0002
e04a02bc
[ 7341.649465] 0001 f326e014 c1f910b0 e04a c0080100 00031c1c e3595ba0
c0080100
[ 7341.658149] Call Trace:
[ 7341.660888] [] sst_post_download_byt+0x58/0xb0
[ 7341.666925] [] sst_load_fw+0xdc/0x510
[ 7341.672086] [] ? __mutex_lock_slowpath+0x250/0x370
[ 7341.678507] [] ? sub_preempt_count+0x55/0xe0
[ 7341.684346] [] sst_download_fw+0x14/0x60
[ 7341.689796] [] ? mutex_lock+0x23/0x30
[ 7341.694954] [] intel_sst_check_device+0x6c/0x120
[ 7341.701181] [] sst_set_generic_params+0x1b8/0x4a0
[ 7341.707504] [] ? sub_preempt_count+0x55/0xe0
[ 7341.713341] [] ? sub_preempt_count+0x55/0xe0
[ 7341.719178] [] ? __mutex_lock_slowpath+0x250/0x370
[ 7341.725600] [] ? __kmalloc_track_caller+0xe4/0x1d0
[ 7341.732022] [] sst_set_mixer_param+0x25/0x40
[ 7341.737859] [] lpe_mixer_ihf_set+0xb3/0x160
[ 7341.743602] [] snd_ctl_ioctl+0xa89/0xb40
[ 7341.749052] [] ? path_openat+0xa5/0x3d0
[ 7341.754409] [] ? avc_has_perm_flags+0xc7/0x170
[ 7341.760441] [] ? snd_ctl_elem_add_user+0x540/0x540
[ 7341.766862] [] do_vfs_ioctl+0x77/0x5e0
[ 7341.772117] [] ? inode_has_perm.isra.42.constprop.79+0x3a/0x50
[ 7341.779705] [] ? file_has_perm+0xa0/0xb0
[ 7341.785155] [] ? selinux_file_ioctl+0x48/0xe0
[ 7341.791090] [] SyS_ioctl+0x78/0x90
[ 7341.795958] [] syscall_call+0x7/0xb
[ 7341.800925] [] ? mm_fault_error+0x13c/0x198
Signed-off-by: jzha144
---
drivers/base/firmware_class.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8a97ddf..2ffd66f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -619,6 +619,7 @@ static ssize_t firmware_loading_store(struct device *dev,
struct firmware_buf *fw_buf;
int loading = simple_strtol(buf, NULL, 10);
int i;
+ size_t size = count;
mutex_lock(_lock);
fw_buf = fw_priv->buf;
@@ -649,7 +650,11 @@ static ssize_t firmware_loading_store(struct device *dev,
* see the mapped 'buf->data' once the loading
* is completed.
* */
- fw_map_pages_buf(fw_buf);
+ if (fw_map_pages_buf(fw_buf)) {
+ size = 0;
+ dev_err(dev, "%s: map pages failed\n",
+ __func__);
+ }
list_del_init(_buf->pending_list);
complete_all(_buf->completion);
break;
@@ -664,7 +669,7 @@ static ssize_t firmware_loading_store(struct device *dev,
}
out:
mutex_unlock(_lock);
- return count;
+ return size;
}
static DEVICE_ATTR(loading, 0644, firmware_loading_show,
firmware_loading_store);
@@ -916,6 +921,8 @@ err_del_dev:
device_del(f_dev);
err_put_dev:
put_device(f_dev);
+ if (!buf->data)
+ return -ENOMEM;
return retval;
}
--
1.7.9.5
Re: [PATCH v4 0/3] ext4: increase mbcache scalability
On 01/28/2014 02:09 PM, Andreas Dilger wrote: > On Jan 28, 2014, at 5:26 AM, George Spelvin wrote: >>> The third part of the patch further increases the scalablity of an ext4 >>> filesystem by having each ext4 fielsystem allocate and use its own private >>> mbcache structure, instead of sharing a single mcache structures across all >>> ext4 filesystems, and increases the size of its mbcache hash tables. >> >> Are you sure this helps? The idea behind having one large mbcache is >> that one large hash table will always be at least as well balanced as >> multiple separate tables, if the total size is the same. >> >> If you have two size 2^n hash tables, the chance of collision is equal to >> one size 2^(n+1) table if they're equally busy, and if they're unequally >> busy. the latter is better. The busier file system will take less time >> per search, and since it's searched more often than the less-busy one, >> net win. >> >> How does it compare with just increasing the hash table size but leaving >> them combined? > > Except that having one mbcache per block device would avoid the need > to store the e_bdev pointer in thousands/millions of entries. Since > the blocks are never shared between different block devices, there > is no caching benefit even if the same block is on two block devices. > > Cheers, Andreas > > > > > Thanks George and Andreas for the comments. Andreas you mentions a good point, e_bdev pointer is not needed when having one mb_cache for each block device. I'll integrate that into my patch, removing the e_bdev pointer, and run some comparison between one large hash table vs multiple hash tables, as suggested by George. Thanks, Mak. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [trivial] net: Fix warning on make htmldocs caused by skbuff.c
From: Masanari Iida Date: Wed, 29 Jan 2014 01:05:28 +0900 > This patch fixed following Warning while executing "make htmldocs". > > Warning(/net/core/skbuff.c:2164): No description found for parameter 'from' > Warning(/net/core/skbuff.c:2164): Excess function parameter 'source' > description in 'skb_zerocopy' > Replace "@source" with "@from" fixed the warning. > > Signed-off-by: Masanari Iida Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] AF_RXRPC fixes
From: David Howells Date: Tue, 28 Jan 2014 17:07:36 + > Here are some small AF_RXRPC fixes. > > (1) Fix a place where a spinlock is taken conditionally but is released > unconditionally. > > (2) Fix a double-free that happens when cleaning up on a checksum error. > > (3) Fix handling of CHECKSUM_PARTIAL whilst delivering messages to userspace. Pulled, 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] i2c-designware-pcidrv: fix the incorrect return of idle callback
> On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote: >> From: "xinhui.pan" >> >> i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do >> success. > > I don't understand... > Sorry for my poor English. Even if i2c_dw_pci_runtime_idle succeed ,it should return -EBUSY. >> Otherwise rpm_idle will call pm_suspend again and that may cause >> pm_schedule_suspend delay invalidate. >> >> Signed-off-by: bo.he >> Signed-off-by: xinhui.pan >> --- >> drivers/i2c/busses/i2c-designware-pcidrv.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c >> b/drivers/i2c/busses/i2c-designware-pcidrv.c >> index f6ed06c..96e81f6 100644 >> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c >> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c >> @@ -190,8 +190,8 @@ static int i2c_dw_pci_runtime_idle(struct device *dev) >> int err = pm_schedule_suspend(dev, 500); >> dev_dbg(dev, "runtime_idle called\n"); >> >> -if (err != 0) >> -return 0; >> +if (err) >> +return err; >> return -EBUSY; > > ... it does return EBUSY when pm_schedule_suspend() succeeds? It only > returns 0 if it does not succeed (for which I don't know if this is an > apropriate behaviour). Mika? > >> } >> >> -- >> 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memblock: Add limit checking to memblock_virt_alloc
On Tue, Jan 28, 2014 at 02:47:57PM -0800, Yinghai Lu wrote: > On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen wrote: > > On 01/28/2014 02:04 PM, Yinghai Lu wrote: > >> In original bootmem wrapper for memblock, we have limit checking. > >> > >> Add it to memblock_virt_alloc, to address arm and x86 booting crash. > >> > >> Signed-off-by: Yinghai Lu > > > > Do you have a git tree or cumulative set of patches that you'd like us > > to all test? I'm happy to boot it on my system, I just want to make > > sure I've got the same set that you're testing. > > This one should only affect on arm and x86 the 32 bit kernel with more > then 4G RAM. Tested-by: Konrad Rzeszutek Wilk It fixes the issue I saw with Xen and 32-bit dom0 blowing up. > > thanks > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] Biscted to 'memblock, nobootmem: add memblock_virt_alloc_low()'
Never mind. I just saw, Zynq is not the only affected ARM platform and the issue is already being discussed on the list: https://lkml.org/lkml/2014/1/28/52 Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 00/16] Volatile Ranges v10
On 01/28/2014 04:03 PM, Johannes Weiner wrote: > Hello Minchan, > > On Thu, Jan 02, 2014 at 04:12:08PM +0900, Minchan Kim wrote: >> Hey all, >> >> Happy New Year! >> >> I know it's bad timing to send this unfamiliar large patchset for >> review but hope there are some guys with freshed-brain in new year >> all over the world. :) >> And most important thing is that before I dive into lots of testing, >> I'd like to make an agreement on design issues and others >> >> o Syscall interface > Why do we need another syscall for this? Can't we extend madvise to > take MADV_VOLATILE, MADV_NONVOLATILE, and return -ENOMEM if something > in the range was purged? So the madvise interface is insufficient to provide the semantics needed. Not so much for MADV_VOLATILE, but MADV_NONVOLATILE. For the NONVOLATILE call, we have to atomically unmark the volatility status of the byte range and provide the purge status, which informs the caller if any of the data in the specified range was discarded (and thus needs to be regenerated). The problem is that by clearing the range, we may need to allocate memory (possibly by splitting in an existing range segment into two), which possibly could fail. Unfortunately this could happen after we've modified the volatile state of part of that range. At this point we can't just fail, because we've modified state and we also need to return the purge status of the modified state. Thus we seem to need a write-like interface, which returns the number of bytes successfully manipulated. But we also have to return the purge state, which we currently do via a argument pointer. hpa suggested to create something like an madvise2 interface which would provide the needed interface change, but would be a shared interface for the new flags as well as the old (possibly allowing various flags to be combined). I'm fine changing it (the interface has changed a number of times already), but we really haven't seen much in the way of a deeper review, so the current vrange syscall is mostly a placeholder to demonstrate the functionality and hopefully spur discussion on the deeper semantics of how volatile ranges should work. >> o Not bind with vma split/merge logic to prevent mmap_sem cost and >> o Not bind with vma split/merge logic to avoid vm_area_struct memory >> footprint. > VMAs are there to track attributes of memory ranges. Duplicating > large parts of their functionality and co-maintaining both structures > on create, destroy, split, and merge means duplicate code and complex > interactions. > > 1. You need to define semantics and coordinate what happens when the >vma underlying a volatile range changes. > >Either you have to strictly co-maintain both range objects, or you >have weird behavior like volatily outliving a vma and then applying >to a separate vma created in its place. So indeed this is a difficult problem! My initial approach is simply when any new mapping is made, we clear the volatility of the affected process memory. Admittedly this has extra overhead and Minchan has an alternative here (which I'm not totally sold on yet, but may be ok). I'm almost convinced that for anonymous volatility, storing the volatility in the vma would be ok, but Minchan is worried about the performance overhead of the required locking for manipulating the vmas. For file volatility, this is more complicated, because since the volatility is shared, the ranges have to be tracked against the address_space structure, and can't be stored in per-process vmas. So this is partially why we've kept range trees hanging off of the mm and address_spaces structures, since it allows the range manipulation logic to be shared in both cases. >Userspace won't get this right, and even in the kernel this is >error prone and adds a lot to the complexity of vma management. Not sure exactly I understand what you mean by "userspace won't get this right" ? > > 2. If page reclaim discards a page from the upper end of a a range, >you mark the whole range as purged. If the user later marks the >lower half of the range as non-volatile, the syscall will report >purged=1 even though all requested pages are still there. To me this aspect is a non-ideal but acceptable result of the usage pattern. Semantically, the hard rule would be we never report non-purged if pages in a range were purged. Reporting purged when pages technically weren't is not optimal but acceptable side effect of unmarking a sub-range. And could be avoided by applications marking and unmarking objects consistently. >The only way to make these semantics clean is either > > a) have vrange() return a range ID so that only full ranges can > later be marked non-volatile, or > > b) remember individual page purges so that sub-range changes can > properly report them > >I don't like a) much because it's somewhat arbitrarily more >restrictive than madvise, mprotect, mmap/munmap etc. Agreed
linux-next: manual merge of the nfsd tree with Linus' tree
Hi all,
Today's linux-next merge of the nfsd tree got a conflict in
fs/nfsd/nfs4acl.c between commit 4ac7249ea5a0 ("nfsd: use get_acl and
->set_acl") from Linus' tree and commit 3554116d3aae ("nfsd4: simplify
xdr encoding of nfsv4 names") from the nfsd 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 fs/nfsd/nfs4acl.c
index 649ad7cf2204,eea24c9a561d..
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
@@@ -37,13 -37,9 +37,14 @@@
#include
#include
#include
+#include "nfsfh.h"
+ #include "nfsd.h"
#include "acl.h"
+#include "vfs.h"
+#define NFS4_ACL_TYPE_DEFAULT 0x01
+#define NFS4_ACL_DIR 0x02
+#define NFS4_ACL_OWNER0x04
/* mode bit translations: */
#define NFS4_READ_MODE (NFS4_ACE_READ_DATA)
@@@ -916,17 -849,26 +917,22 @@@ nfs4_acl_get_whotype(char *p, u32 len
return NFS4_ACL_WHO_NAMED;
}
- int
- nfs4_acl_write_who(int who, char *p)
+ __be32 nfs4_acl_write_who(int who, __be32 **p, int *len)
{
int i;
+ int bytes;
for (i = 0; i < ARRAY_SIZE(s2t_map); i++) {
- if (s2t_map[i].type == who) {
- memcpy(p, s2t_map[i].string, s2t_map[i].stringlen);
- return s2t_map[i].stringlen;
- }
+ if (s2t_map[i].type != who)
+ continue;
+ bytes = 4 + (XDR_QUADLEN(s2t_map[i].stringlen) << 2);
+ if (bytes > *len)
+ return nfserr_resource;
+ *p = xdr_encode_opaque(*p, s2t_map[i].string,
+ s2t_map[i].stringlen);
+ *len -= bytes;
+ return 0;
}
- BUG();
+ WARN_ON_ONCE(1);
return -1;
}
-
-EXPORT_SYMBOL(nfs4_acl_new);
-EXPORT_SYMBOL(nfs4_acl_get_whotype);
-EXPORT_SYMBOL(nfs4_acl_write_who);
pgp2UwckCXLPJ.pgp
Description: PGP signature
Re: [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in numa_clear_kernel_node_hotplug().
Hi Ingo,
On 01/28/2014 07:48 PM, Ingo Molnar wrote:
>
> * David Rientjes wrote:
>
>> On Tue, 28 Jan 2014, Tang Chen wrote:
>>
>>> On-stack variable numa_kernel_nodes in numa_clear_kernel_node_hotplug()
>>> was not initialized. So we need to initialize it.
>>>
>>> Signed-off-by: Tang Chen
>>> Tested-by: Gu Zheng
>>
>> Reported-by: David Rientjes
>
> Agreed. Tang Chen, please also spell it out in the changelog:
>
>David Rientjes reported a boot crash, caused by
>commit XYZ ("foo: bar").
>
> I find it somewhat annoying that you found time to credit a corporate
> collegue with a Tested-by tag, who didn't even reply to the whole
> thread to indicate his testing efforts,
Sorry for missing to indicate the test result, because I am really busy with
some thorny issues. If Tang did not remind me, maybe I'll miss the whole thread.
But I think the "Tested-by:" is the best confirmation of the testing efforts,
it indicates that the guy has nearly completely tested the patch on his
environment.
Thanks,
Gu
> but you didn't find the time
> to credit the original reporter of the bug who also reviewed your
> patches ...
>
> 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/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] memblock: Add limit checking to memblock_virt_alloc
On Tue, Jan 28, 2014 at 2:04 PM, Yinghai Lu wrote: > In original bootmem wrapper for memblock, we have limit checking. > > Add it to memblock_virt_alloc, to address arm and x86 booting crash. > > Signed-off-by: Yinghai Lu > > --- > mm/memblock.c |3 +++ > 1 file changed, 3 insertions(+) > > Index: linux-2.6/mm/memblock.c > === > --- linux-2.6.orig/mm/memblock.c > +++ linux-2.6/mm/memblock.c > @@ -1077,6 +1077,9 @@ static void * __init memblock_virt_alloc > if (!align) > align = SMP_CACHE_BYTES; > > + if (max_addr > memblock.current_limit) > + max_addr = memblock.current_limit; > + > again: > alloc = memblock_find_in_range_node(size, align, min_addr, max_addr, > nid); Tested-by: Kevin Hilman Verified various ARM boots to be passing again. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] mm, hugetlb: fix race in region tracking
On Tue, 2014-01-28 at 19:36 -0500, Naoya Horiguchi wrote: > On Mon, Jan 27, 2014 at 06:34:17PM -0800, Davidlohr Bueso wrote: [...] > > > If this retry is really essential for the fix, please comment the reason > > > both in patch description and inline comment. It's very important for > > > future code maintenance. > > > > So we locate the corresponding region in the reserve map, and if we are > > below the current region, then we allocate a new one. Since we dropped > > the lock to allocate memory, we have to make sure that we still need the > > new region and that we don't race with the new status of the reservation > > map. This is the whole point of the retry, and I don't see it being > > suboptimal. > > I'm afraid that you don't explain why you need drop the lock for memory > allocation. Are you saying that this unlocking comes from the difference > between rwsem and spin lock? Because you cannot go to sleep while holding a spinlock, which is exactly what kmalloc(GFP_KERNEL) can do. We *might* get a way with it with GFP_ATOMIC, I dunno, but I certainly prefer this approach better. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: manual merge of the imx-mxs tree with the arm tree
On Wed, Jan 29, 2014 at 01:13:10AM +, Russell King - ARM Linux wrote:
> On Wed, Jan 29, 2014 at 11:35:14AM +1100, Stephen Rothwell wrote:
> > Hi Shawn,
> >
> > Today's linux-next merge of the imx-mxs tree got a conflict in
> > arch/arm/boot/dts/Makefile between commits 208d7baf8085 ("ARM: imx:
> > initial SolidRun HummingBoard support") and 971488f1149f ("ARM: imx:
> > initial SolidRun Cubox-i support") from the arm tree and various commits
> > from the imx-mxs tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> Nice easy add/add which Linus won't complain about. Thanks Stephen.
>
> This should move to between Linus' and Shawn's tree over the next
> couple of days since I've now sent my final pull request for this
> window.
I will rebase my branch on v3.14-rc1 once it's out.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the imx-mxs tree with the arm tree
On Wed, Jan 29, 2014 at 11:35:14AM +1100, Stephen Rothwell wrote:
> Hi Shawn,
>
> Today's linux-next merge of the imx-mxs tree got a conflict in
> arch/arm/boot/dts/Makefile between commits 208d7baf8085 ("ARM: imx:
> initial SolidRun HummingBoard support") and 971488f1149f ("ARM: imx:
> initial SolidRun Cubox-i support") from the arm tree and various commits
> from the imx-mxs tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Nice easy add/add which Linus won't complain about. Thanks Stephen.
This should move to between Linus' and Shawn's tree over the next
couple of days since I've now sent my final pull request for this
window.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] XFS update #2 for 3.14-rc1
Hi Linus, Please pull this xfs update for 3.14. This is to allow logical sector sized direct io on advanced format disks. Thanks, Ben The following changes since commit bf3964c188d686424ff7b69a45941851b9f437f0: Merge branch 'xfs-extent-list-locking-fixes' into for-next (2014-01-09 16:03:18 -0600) are available in the git repository at: git://oss.sgi.com/xfs/xfs.git tags/xfs-for-linus-v3.14-rc1-2 for you to fetch changes up to 7c71ee78031c248dca13fc94dea9a4cc217db6cf: xfs: allow logical-sector sized O_DIRECT (2014-01-24 11:55:42 -0600) xfs: update #2 for v3.14-rc1 - allow logical sector sized direct io on 'advanced format' 4k/512 disk. Eric Sandeen (3): xfs: clean up xfs_buftarg xfs: rename xfs_buftarg structure members xfs: allow logical-sector sized O_DIRECT fs/xfs/xfs_buf.c | 14 +- fs/xfs/xfs_buf.h | 20 +--- fs/xfs/xfs_file.c | 7 +-- fs/xfs/xfs_ioctl.c | 2 +- 4 files changed, 32 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the btrfs tree with Linus' tree
Hi all,
Today's linux-next merge of the btrfs tree got a conflict in
fs/btrfs/acl.c between commit 996a710d4641 ("btrfs: use generic posix ACL
infrastructure") from the tree and commit cfad95253440 ("btrfs: remove
dead code") from the btrfs tree.
I fixed it up (I used the version from Linus' tree) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpDX3OxaiJ26.pgp
Description: PGP signature
[REGRESSION] Biscted to 'memblock, nobootmem: add memblock_virt_alloc_low()'
Hi all, I just found that the current Linux tree (HEAD@ d891ea23d5203e5c47439b2a174f86a00b356a6c ) fails to boot on Zynq (ARM). The system runs into a panic relatively early (full boot log attached): [0.00] Unable to handle kernel paging request at virtual address ffc0 [0.00] pgd = c0004000 [0.00] [ffc0] *pgd=2e7f6821, *pte=, *ppte= [0.00] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-xilinx-08988-gd891ea23d520 #22 [0.00] task: c0385ab0 ti: c037c000 task.ti: c037c000 [0.00] PC is at __memzero+0x4c/0x80 [0.00] LR is at 0x0 [0.00] pc : []lr : [<>]psr: 01d3 [0.00] sp : c037df0c ip : fp : [0.00] r10: r9 : r8 : 3fc0 [0.00] r7 : r6 : ffc0 r5 : 0040 r4 : 001c [0.00] r3 : r2 : r1 : ffdc r0 : ffc0 [0.00] Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 18c5387d Table: 404a DAC: 0015 [0.00] Process swapper (pid: 0, stack limit = 0xc037c240) [0.00] Stack: (0xc037df0c to 0xc037e000) [0.00] df00:c0365cfc 001c [0.00] df20: 413fc090 c038704c c0365f08 c0370368 [0.00] df40: 1000 0002e7f5 1000 0007 c038dff0 c0370368 c039ebf4 c037dfd4 [0.00] df60: c0370368 c039ebf4 c08ef12c c038704c c038dff0 c035aabc 18c5387d [0.00] df80: 406a 413fc090 c03843c0 c025eb74 c02f23a9 c037dfb4 [0.00] dfa0: c0008200 c037c000 0001 c039e840 406a c03843c0 c0357854 [0.00] dfc0: c0372918 18c5387d c0384410 [0.00] dfe0: c0372914 c038717c 406a 413fc090 8074 [0.00] Code: e3110020 18a0500c 18a0500c e3110010 (18a0500c) [0.00] ---[ end trace 15c15b4afa9eff8e ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! I bisected this issue down to commit: ad6492b80f60a2139fa9bf8fd79b182fe5e3647c is the first bad commit commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c Author: Yinghai Lu Date: Mon Jan 27 17:06:49 2014 -0800 memblock, nobootmem: add memblock_virt_alloc_low() The new memblock_virt APIs are used to replaced old bootmem API. We need to allocate page below 4G for swiotlb. That should fix regression on Andrew's system that is using swiotlb. Signed-off-by: Yinghai Lu Cc: Russell King Cc: Konrad Rzeszutek Wilk Acked-by: Santosh Shilimkar Cc: Dave Hansen Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds :04 04 75086461d0b57fca2e767b9be2e660a3fc34fc8b 2365645efe4f6ad75fcfaab3e59da2d9cf0968a2 M arch :04 04 106df01421a1d64347ee050c854e2540064a060b fab0ad7e09604c1ce795abdee894896619822838 M include :04 04 f67991f1b98d03d9791883a5b714bb1d8e6ae596 f6067483b5d7a5688bd873e75a3b4e89df104234 M lib Reverting that commit on top of HEAD results in a booting system again. I also attached my kernel config. Is this somehow related to this discussion regarding the non-DMAabble memory (though that case doesn't seem to panic): https://lkml.org/lkml/2014/1/27/212 ? Thanks, Sören U-Boot 2013.10 (Jan 13 2014 - 14:43:20) I2C: ready Memory: ECC disabled DRAM: 1 GiB MMC: zynq_sdhci: 0 SF: Detected S25FL128S_64K with page size 512 Bytes, erase size 128 KiB, total 32 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Gem.e000b000 Hit any key to stop autoboot: 3 2 1 0 TFTPing Linux to RAM... Gem.e000b000 Waiting for PHY auto negotiation to complete.. done Using Gem.e000b000 device TFTP from server 10.10.70.101; our IP address is 10.10.70.102 Filename 'uImage'. Load address: 0x300 Loading: *##T ### # # 104.5 KiB/s done Bytes transferred = 1919032 (1d4838 hex) Gem.e000b000:7 is connected to Gem.e000b000. Reconnecting to Gem.e000b000 Gem.e000b000 Waiting for PHY auto negotiation to complete... done Using Gem.e000b000 device TFTP from server 10.10.70.101; our IP address is 10.10.70.102 Filename 'devicetree.dtb'. Load address: 0x2a0 Loading: *# 65.4 KiB/s done Bytes transferred = 3363 (d23 hex) Gem.e000b000:7 is connected to Gem.e000b000. Reconnecting to Gem.e000b000 Gem.e000b000 Waiting for PHY auto negotiation to complete... done Using Gem.e000b000 device TFTP from server 10.10.70.101; our IP
Re: [GIT PULL] Core block IO changes for 3.14
Hi Jens and Stephen,
In the case of f2fs, could you please check the following code changes?
It is based on the following commit from Linus tree.
commit d891ea23d5203e5c47439b2a174f86a00b356a6c
Merge: 08d21b5 125d725
Author: Linus Torvalds
Date: Tue Jan 28 11:02:23 2014 -0800
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
---
fs/f2fs/data.c | 31 ++-
include/trace/events/f2fs.h | 4 ++--
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0ae5587..55ae30a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -26,40 +26,37 @@
static void f2fs_read_end_io(struct bio *bio, int err)
{
- const int uptodate = test_bit(BIO_UPTODATE, >bi_flags);
- struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
+ struct bio_vec *bvec;
+ int i;
- do {
+ bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- if (--bvec >= bio->bi_io_vec)
- prefetchw(>bv_page->flags);
-
- if (unlikely(!uptodate)) {
+ if (unlikely(err)) {
ClearPageUptodate(page);
SetPageError(page);
} else {
SetPageUptodate(page);
}
unlock_page(page);
- } while (bvec >= bio->bi_io_vec);
+ }
bio_put(bio);
}
static void f2fs_write_end_io(struct bio *bio, int err)
{
- const int uptodate = test_bit(BIO_UPTODATE, >bi_flags);
- struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
- struct f2fs_sb_info *sbi =
F2FS_SB(bvec->bv_page->mapping->host->i_sb);
+ struct f2fs_sb_info *sbi = NULL;
+ struct bio_vec *bvec;
+ int i;
- do {
+ bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- if (--bvec >= bio->bi_io_vec)
- prefetchw(>bv_page->flags);
+ if (!sbi)
+ sbi = F2FS_SB(bvec->bv_page->mapping->host->i_sb);
- if (unlikely(!uptodate)) {
+ if (unlikely(err)) {
SetPageError(page);
set_bit(AS_EIO, >mapping->flags);
set_ckpt_flags(sbi->ckpt, CP_ERROR_FLAG);
@@ -67,7 +64,7 @@ static void f2fs_write_end_io(struct bio *bio, int
err)
}
end_page_writeback(page);
dec_page_count(sbi, F2FS_WRITEBACK);
- } while (bvec >= bio->bi_io_vec);
+ }
if (bio->bi_private)
complete(bio->bi_private);
@@ -91,7 +88,7 @@ static struct bio *__bio_alloc(struct f2fs_sb_info
*sbi, block_t blk_addr,
bio = bio_alloc(GFP_NOIO, npages);
bio->bi_bdev = sbi->sb->s_bdev;
- bio->bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
+ bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
bio->bi_end_io = is_read ? f2fs_read_end_io : f2fs_write_end_io;
return bio;
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index 3b9f28d..67f38fa 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -629,8 +629,8 @@ DECLARE_EVENT_CLASS(f2fs__submit_bio,
__entry->dev= sb->s_dev;
__entry->rw = rw;
__entry->type = type;
- __entry->sector = bio->bi_sector;
- __entry->size = bio->bi_size;
+ __entry->sector = bio->bi_iter.bi_sector;
+ __entry->size = bio->bi_iter.bi_size;
),
TP_printk("dev = (%d,%d), %s%s, %s, sector = %lld, size = %u",
--
1.8.4.474.g128a96c
Thanks,
2014-01-29 (수), 11:05 +1100, Stephen Rothwell:
> Hi all,
>
> On Tue, 28 Jan 2014 15:52:29 -0700 Jens Axboe wrote:
> >
> > On Tue, Jan 28 2014, Jens Axboe wrote:
> > >
> > > This is the pull request for the core block IO changes for 3.14. The
> > > major piece in here is the immutable bio_ve series from Kent, the rest
> > > is fairly minor. It was supposed to go in last round, but various issues
> > > pushed it to this release instead. The pull request contains:
> > >
> > >
> > > - Various smaller blk-mq fixes from different folks. Nothing major here,
> > > just minor fixes and cleanups.
> > >
> > > - Fix for a memory leak in the error path in the block ioctl code from
> > > Christian Engelmayer.
> > >
> > > - Header export fix from CaiZhiyong.
> > >
> > > - Finally the immutable biovec changes from Kent Overstreet. This
> > > enables some nice future work on making arbitrarily sized bios
> > > possible, and splitting more efficient. Related fixes to immutable
> > > bio_vecs:
> > >
> > > - dm-cache immutable fixup from Mike Snitzer.
> > > - btrfs immutable fixup from
Re: [PATCH 3/8] mm, hugetlb: fix race in region tracking
On Mon, Jan 27, 2014 at 06:34:17PM -0800, Davidlohr Bueso wrote:
> On Mon, 2014-01-27 at 20:53 -0500, Naoya Horiguchi wrote:
> > Hi Davidlohr,
> >
> > On Mon, Jan 27, 2014 at 01:44:02PM -0800, Davidlohr Bueso wrote:
> > > On Mon, 2014-01-27 at 16:02 -0500, Naoya Horiguchi wrote:
> > > > On Sun, Jan 26, 2014 at 07:52:21PM -0800, Davidlohr Bueso wrote:
> > > > > From: Joonsoo Kim
> > > > >
> > > > > There is a race condition if we map a same file on different
> > > > > processes.
> > > > > Region tracking is protected by mmap_sem and
> > > > > hugetlb_instantiation_mutex.
> > > > > When we do mmap, we don't grab a hugetlb_instantiation_mutex, but
> > > > > only the,
> > > > > mmap_sem (exclusively). This doesn't prevent other tasks from
> > > > > modifying the
> > > > > region structure, so it can be modified by two processes concurrently.
> > > > >
> > > > > To solve this, introduce a spinlock to resv_map and make region
> > > > > manipulation
> > > > > function grab it before they do actual work.
> > > > >
> > > > > Acked-by: David Gibson
> > > > > Signed-off-by: Joonsoo Kim
> > > > > [Updated changelog]
> > > > > Signed-off-by: Davidlohr Bueso
> > > > > ---
> > > > ...
> > > > > @@ -203,15 +200,23 @@ static long region_chg(struct resv_map *resv,
> > > > > long f, long t)
> > > > >* Subtle, allocate a new region at the position but make it
> > > > > zero
> > > > >* size such that we can guarantee to record the reservation. */
> > > > > if (>link == head || t < rg->from) {
> > > > > - nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> > > > > - if (!nrg)
> > > > > - return -ENOMEM;
> > > > > + if (!nrg) {
> > > > > + spin_unlock(>lock);
> > > >
> > > > I think that doing kmalloc() inside the lock is simpler.
> > > > Why do you unlock and retry here?
> > >
> > > This is a spinlock, no can do -- we've previously debated this and since
> > > the critical region is quite small, a non blocking lock is better suited
> > > here. We do the retry so we don't race once the new region is allocated
> > > after the lock is dropped.
> >
> > Using spinlock instead of rw_sem makes sense.
> > But I'm not sure how the retry is essential to fix the race.
> > (Sorry I can't find the discussion log about this.)
> > As you did in your ver.1 (https://lkml.org/lkml/2013/7/26/296),
> > simply doing like below seems to be fine to me, is it right?
> >
> > if (>link == head || t < rg->from) {
> > nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> > if (!nrg) {
> > chg = -ENOMEM;
> > goto out_locked;
> > }
> > nrg->from = f;
> > ...
> > }
>
> That's nice and simple because we were using the rwsem version.
>
> >
> > In the current version nrg is initialized to NULL, so we always do retry
> > once when adding new file_region. That's not optimal to me.
>
> Right, the retry can only occur once.
>
> >
> > If this retry is really essential for the fix, please comment the reason
> > both in patch description and inline comment. It's very important for
> > future code maintenance.
>
> So we locate the corresponding region in the reserve map, and if we are
> below the current region, then we allocate a new one. Since we dropped
> the lock to allocate memory, we have to make sure that we still need the
> new region and that we don't race with the new status of the reservation
> map. This is the whole point of the retry, and I don't see it being
> suboptimal.
I'm afraid that you don't explain why you need drop the lock for memory
allocation. Are you saying that this unlocking comes from the difference
between rwsem and spin lock?
I think if we call kmalloc() with the lock held we don't have to check
that "we still need the new region" because resv->lock guarantees that
no other thread changes the reservation map, right?
> We just cannot retake the lock after we get the new region and just add
> it to to the list.
>
> >
> > And I noticed another point. I don't think the name of new goto label
> > 'out_locked' is a good one. 'out_unlock' or 'unlock' is better.
>
> What worries me more is that we're actually freeing a valid new region
> (nrg) upon exit. We certainly don't do so in the current code, and it
> doesn't seem to be a leak. Instead, we should be doing:
You're right. There is another goto in region_chg() where we never do
the kmalloc, so calling kfree is a bug.
Thanks,
Naoya Horiguchi
> if (>link == head || t < rg->from) {
> if (!nrg) {
> spin_unlock(>lock);
> nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> if (!nrg)
> return -ENOMEM;
>
> goto retry;
> }
>
> nrg->from = f;
> nrg->to = f;
> INIT_LIST_HEAD(>link);
>
linux-next: manual merge of the imx-mxs tree with the arm tree
Hi Shawn,
Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/boot/dts/Makefile between commits 208d7baf8085 ("ARM: imx:
initial SolidRun HummingBoard support") and 971488f1149f ("ARM: imx:
initial SolidRun Cubox-i support") from the arm tree and various commits
from the imx-mxs 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 arch/arm/boot/dts/Makefile
index b9d6a8b485e0,2841184f354c..
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -150,15 -137,32 +153,35 @@@ dtb-$(CONFIG_ARCH_MXC) +=
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-qsb.dtb \
+ imx53-qsrb.dtb \
imx53-smd.dtb \
+ imx53-tx53-x03x.dtb \
+ imx53-tx53-x13x.dtb \
+ imx53-voipac-bsb.dtb \
+ imx6dl-cubox-i.dtb \
+ imx6dl-dfi-fs700-m60.dtb \
+ imx6dl-gw51xx.dtb \
+ imx6dl-gw52xx.dtb \
+ imx6dl-gw53xx.dtb \
+ imx6dl-gw54xx.dtb \
+ imx6dl-hummingboard.dtb \
+ imx6dl-nitrogen6x.dtb \
imx6dl-sabreauto.dtb \
+ imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
imx6dl-wandboard.dtb \
imx6q-arm2.dtb \
+ imx6q-cm-fx6.dtb \
+ imx6q-cubox-i.dtb \
+ imx6q-dfi-fs700-m60.dtb \
+ imx6q-dmo-edmqmx6.dtb \
+ imx6q-gk802.dtb \
+ imx6q-gw51xx.dtb \
+ imx6q-gw52xx.dtb \
+ imx6q-gw53xx.dtb \
+ imx6q-gw5400-a.dtb \
+ imx6q-gw54xx.dtb \
+ imx6q-nitrogen6x.dtb \
imx6q-phytec-pbab01.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
pgpur_WEG2nS3.pgp
Description: PGP signature
Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
So the 1-2 threads case is the standard case on a small system, isn't it? This may well cause regressions. > In the extremely unlikely case that all the queue node entries are > used up, the current code will fall back to busy spinning without > waiting in a queue with warning message. Traditionally we had some code which could take thousands of locks in rare cases (e.g. all locks in a hash table or all locks of a big reader lock) The biggest offender was the mm for changing mmu notifiers, but I believe that's a mutex now. lglocks presumably still can do it on large enough systems. I wouldn't be surprised if there is other code which e.g. make take all locks in a table. I don't think the warning is valid and will likely trigger in some obscure cases. -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/
[GIT PULL] x86 platform drivers for 3.14
Hi Linus, Nothing amazingly special here. Some cleanups, a new driver to support a single button on some new HPs, a tiny amount of hardware enablement. The following changes since commit ec513b16c480c6cdda1e3d597e611eafca05227b: Merge tag 'usb-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2014-01-20 16:13:02 -0800) are available in the git repository at: git://cavan.codon.org.uk/platform-drivers-x86.git for_linus for you to fetch changes up to b4b0b4a9e0392dbd00e5f033e1329ce61ed06fef: ipc: add intel-mid's pci id macros (2014-01-21 08:47:15 -0500) Alex Hung (1): hp-wireless: new driver for hp wireless button for Windows 8 Colin Ian King (1): sony-laptop: remove unnecessary assigment of len David Cohen (2): ipc: simplify platform data approach ipc: add intel-mid's pci id macros David E. Box (1): X86 platform: New BayTrail IOSF-SB MBI driver Guenter Roeck (5): compal-laptop: Use devm_kzalloc to allocate local data structure eeepc-laptop: Convert to use devm_hwmon_device_register_with_groups compal-laptop: Replace SENSOR_DEVICE_ATTR with DEVICE_ATTR compal-laptop: Use devm_hwmon_device_register_with_groups asus-wmi: Convert to use devm_hwmon_device_register_with_groups Hans de Goede (2): dell-laptop: rkill whitelist Precision models dell-laptop: Only install the i8042 filter when rfkill is active Julia Lawall (1): fujitsu-laptop: fix error return code Rashika Kheria (2): drivers: platform: Mark functions as static in hp_accel.c drivers: platform: Include appropriate header file in mxm-wmi.c Takashi Iwai (1): hp_accel: Add a new PnP ID HPQ6007 for new HP laptops Unai Uribarri (1): toshiba_acpi: Support RFKILL hotkey scancode Wei Yongjun (1): dell-laptop: fix to return error code in dell_send_intensity() drivers/platform/x86/Kconfig | 19 +++ drivers/platform/x86/Makefile | 2 + drivers/platform/x86/asus-wmi.c | 48 ++-- drivers/platform/x86/compal-laptop.c | 121 +- drivers/platform/x86/dell-laptop.c| 78 ++-- drivers/platform/x86/eeepc-laptop.c | 52 ++-- drivers/platform/x86/fujitsu-laptop.c | 15 ++- drivers/platform/x86/hp-wireless.c| 132 drivers/platform/x86/hp_accel.c | 7 +- drivers/platform/x86/intel_baytrail.c | 224 ++ drivers/platform/x86/intel_baytrail.h | 90 ++ drivers/platform/x86/intel_scu_ipc.c | 87 ++--- drivers/platform/x86/mxm-wmi.c| 1 + drivers/platform/x86/sony-laptop.c| 2 +- drivers/platform/x86/toshiba_acpi.c | 1 + 15 files changed, 642 insertions(+), 237 deletions(-) create mode 100644 drivers/platform/x86/hp-wireless.c create mode 100644 drivers/platform/x86/intel_baytrail.c create mode 100644 drivers/platform/x86/intel_baytrail.h -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-intel-mid: fix the incorrect return of idle callback
On Tue, Jan 28, 2014 at 12:12:06PM -0600, Felipe Balbi wrote:
> On Tue, Jan 28, 2014 at 09:24:13AM -0800, David Cohen wrote:
> > On Tue, Jan 28, 2014 at 10:49:37AM -0600, Felipe Balbi wrote:
> > > On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> > > > From: "xinhui.pan"
> > > >
> > > > intel_gpio_runtime_idle should return correct error code if it do fail.
> > > > make it more correct even though -EBUSY is the most possible return
> > > > value.
> > > >
> > > > Signed-off-by: bo.he
> > > > Signed-off-by: xinhui.pan
> > > > ---
> > > > drivers/gpio/gpio-intel-mid.c |4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpio/gpio-intel-mid.c
> > > > b/drivers/gpio/gpio-intel-mid.c
> > > > index d1b50ef..05749a3 100644
> > > > --- a/drivers/gpio/gpio-intel-mid.c
> > > > +++ b/drivers/gpio/gpio-intel-mid.c
> > > > @@ -394,7 +394,9 @@ static const struct irq_domain_ops
> > > > intel_gpio_irq_ops = {
> > > >
> > > > static int intel_gpio_runtime_idle(struct device *dev)
> > > > {
> > > > - pm_schedule_suspend(dev, 500);
> > > > + int err = pm_schedule_suspend(dev, 500);
> > > > + if (err)
> > > > + return err;
> > > > return -EBUSY;
> > >
> > > wait, is it only me or this would look a lot better as:
> > >
> > > static int intel_gpio_runtime_idle(struct device *dev)
> > > {
> > > return pm_schedule_suspend(dev, 500);
> > > }
> >
> > The reply to your suggestion is probably in this commit :)
> >
> > ---
> > commit 45f0a85c8258741d11bda25c0a5669c06267204a
> > Author: Rafael J. Wysocki
> > Date: Mon Jun 3 21:49:52 2013 +0200
> >
> > PM / Runtime: Rework the "runtime idle" helper routine
> > ---
> >
> > We won't return 0 from here.
>
> so you never want to return 0, why don't you, then:
>
> static int intel_gpio_runtime_idle(struct device *dev)
> {
> pm_schedule_suspend(dev, 500);
> return -EBUSY;
> }
That's how it is currently :)
But this patch is making the function to return a different code in case
of error. IMHO there is not much fuctional gain with it, but I see
perhaps one extra info for tracing during development.
Anyway, I'll let Xinhui to do further comment since he's the author.
Br, David
>
> just like drivers/tty/serial/mfd.c::serial_hsu_runtime_idle() is doing ?
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] nohz: ensure users are aware boot CPU is not NO_HZ_FULL
On Tue, Jan 28, 2014 at 12:10:49PM -0500, Paul Gortmaker wrote: > This bit of information is in the Kconfig help text: > > Note the boot CPU will still be kept outside the range to > handle the timekeeping duty. > > However neither the variable NO_HZ_FULL_ALL, or the prompt > convey this important detail, so lets add it to the prompt > to make it more explicitly obvious to the average user. > > Cc: Frederic Weisbecker > Cc: "Paul E. McKenney" > Signed-off-by: Paul Gortmaker Acked-by: Paul E. McKenney > --- > kernel/time/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig > index 3ce6e8c5f3fc..76a1fbef1fd8 100644 > --- a/kernel/time/Kconfig > +++ b/kernel/time/Kconfig > @@ -124,7 +124,7 @@ config NO_HZ_FULL > endchoice > > config NO_HZ_FULL_ALL > - bool "Full dynticks system on all CPUs by default" > + bool "Full dynticks system on all (but boot) CPUs by default" > depends on NO_HZ_FULL > help > If the user doesn't pass the nohz_full boot option to > -- > 1.8.5.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: [GIT PULL] Core block IO changes for 3.14
Hi all,
On Tue, 28 Jan 2014 15:52:29 -0700 Jens Axboe wrote:
>
> On Tue, Jan 28 2014, Jens Axboe wrote:
> >
> > This is the pull request for the core block IO changes for 3.14. The
> > major piece in here is the immutable bio_ve series from Kent, the rest
> > is fairly minor. It was supposed to go in last round, but various issues
> > pushed it to this release instead. The pull request contains:
> >
> >
> > - Various smaller blk-mq fixes from different folks. Nothing major here,
> > just minor fixes and cleanups.
> >
> > - Fix for a memory leak in the error path in the block ioctl code from
> > Christian Engelmayer.
> >
> > - Header export fix from CaiZhiyong.
> >
> > - Finally the immutable biovec changes from Kent Overstreet. This
> > enables some nice future work on making arbitrarily sized bios
> > possible, and splitting more efficient. Related fixes to immutable
> > bio_vecs:
> >
> > - dm-cache immutable fixup from Mike Snitzer.
> > - btrfs immutable fixup from Muthu Kumar.
> >
> > - bio-integrity fix from Nic Bellinger, which is also going to stable.
> >
> >
> > Please pull! There will be a bit of merge work for you, but it should be
> > fairly straight forward. It's mostly related to changin:
> >
> > bio->bi_sector -> bio->bi_iter.bi_sector
> > bio->bi_size-> bio->bi_iter.bi_size
> >
> >
> > git://git.kernel.dk/linux-block.git for-3.14/core
>
> BTW, let me know if you want me to merge this. The above has been in
> for-next since forever, and Stephen has carried a fix or two for new
> merges.
The worst bit is the conflicts with the f2fs changes that have already
been merged. My current merge commit looks like this (though I don't
remember getting any comments on my fixes):
da3f6c793c656a022453df8bf458d13e5a353beb
diff --cc drivers/md/dm-thin.c
index 726228b33a01,357eb272dbd9..faaf944597ab
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@@ -1258,8 -1262,8 +1264,8 @@@ static void process_bio_read_only(struc
r = dm_thin_find_block(tc->td, block, 1, _result);
switch (r) {
case 0:
- if (lookup_result.shared && (rw == WRITE) && bio->bi_size)
+ if (lookup_result.shared && (rw == WRITE) &&
bio->bi_iter.bi_size)
- bio_io_error(bio);
+ handle_unserviceable_bio(tc->pool, bio);
else {
inc_all_io_entry(tc->pool, bio);
remap_and_issue(tc, bio, lookup_result.block);
diff --cc drivers/md/raid10.c
index 8d39d63281b9,6d43d88657aa..33fc408e5eac
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@@ -1319,8 -1256,8 +1256,8 @@@ read_again
/* Could not read all from this device, so we will
* need another r10_bio.
*/
- sectors_handled = (r10_bio->sectors + max_sectors
+ sectors_handled = (r10_bio->sector + max_sectors
- - bio->bi_sector);
+ - bio->bi_iter.bi_sector);
r10_bio->sectors = max_sectors;
spin_lock_irq(>device_lock);
if (bio->bi_phys_segments == 0)
diff --cc fs/btrfs/extent_io.c
index fbe501d3bd01,bcb6f1b780d6..85bbd01f1271
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -2375,12 -2332,15 +2375,13 @@@ int end_extent_writepage(struct page *p
*/
static void end_bio_extent_writepage(struct bio *bio, int err)
{
- struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
+ struct bio_vec *bvec;
- struct extent_io_tree *tree;
u64 start;
u64 end;
+ int i;
- do {
+ bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- tree = _I(page->mapping->host)->io_tree;
/* We always issue full-page reads, but if some block
* in a page fails to read, blk_update_request() will
diff --cc fs/btrfs/inode.c
index 1ef056837755,7ab0e94ad492..f0422a5efa78
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -7016,10 -6891,11 +7013,11 @@@ static void btrfs_end_dio_bio(struct bi
struct btrfs_dio_private *dip = bio->bi_private;
if (err) {
- printk(KERN_ERR "btrfs direct IO failed ino %llu rw %lu "
-"sector %#Lx len %u err no %d\n",
+ btrfs_err(BTRFS_I(dip->inode)->root->fs_info,
+"direct IO failed ino %llu rw %lu sector %#Lx len %u
err no %d",
btrfs_ino(dip->inode), bio->bi_rw,
- (unsigned long long)bio->bi_sector, bio->bi_size, err);
+ (unsigned long long)bio->bi_iter.bi_sector,
+ bio->bi_iter.bi_size, err);
dip->errors = 1;
/*
diff --cc fs/f2fs/data.c
index 0ae558723506,a2c8de8ba6ce..25d675e6a138
Re: [PATCH v10 00/16] Volatile Ranges v10
Hello Minchan, On Thu, Jan 02, 2014 at 04:12:08PM +0900, Minchan Kim wrote: > Hey all, > > Happy New Year! > > I know it's bad timing to send this unfamiliar large patchset for > review but hope there are some guys with freshed-brain in new year > all over the world. :) > And most important thing is that before I dive into lots of testing, > I'd like to make an agreement on design issues and others > > o Syscall interface Why do we need another syscall for this? Can't we extend madvise to take MADV_VOLATILE, MADV_NONVOLATILE, and return -ENOMEM if something in the range was purged? > o Not bind with vma split/merge logic to prevent mmap_sem cost and > o Not bind with vma split/merge logic to avoid vm_area_struct memory > footprint. VMAs are there to track attributes of memory ranges. Duplicating large parts of their functionality and co-maintaining both structures on create, destroy, split, and merge means duplicate code and complex interactions. 1. You need to define semantics and coordinate what happens when the vma underlying a volatile range changes. Either you have to strictly co-maintain both range objects, or you have weird behavior like volatily outliving a vma and then applying to a separate vma created in its place. Userspace won't get this right, and even in the kernel this is error prone and adds a lot to the complexity of vma management. 2. If page reclaim discards a page from the upper end of a a range, you mark the whole range as purged. If the user later marks the lower half of the range as non-volatile, the syscall will report purged=1 even though all requested pages are still there. The only way to make these semantics clean is either a) have vrange() return a range ID so that only full ranges can later be marked non-volatile, or b) remember individual page purges so that sub-range changes can properly report them I don't like a) much because it's somewhat arbitrarily more restrictive than madvise, mprotect, mmap/munmap etc. And for b), the straight-forward solution would be to put purge-cookies into the page tables to properly report purges in subrange changes, but that would be even more coordination between vmas, page tables, and the ad-hoc vranges. 3. Page reclaim usually happens on individual pages until an allocation can be satisfied, but the shrinker purges entire ranges. Should it really take out an entire 1G volatile range even though 4 pages would have been enough to satisfy an allocation? Sure, we assume a range represents an single "object" and userspace would have to regenerate the whole thing with only one page missing, but there is still a massive difference in page frees, faults, and allocations. There needs to be a *really* good argument why VMAs are not enough for this purpose. I would really like to see anon volatility implemented as a VMA attribute, and have regular reclaim decide based on rmap of individual pages whether it needs to swap or purge. Something like this: MADV_VOLATILE: split vma if necessary set VM_VOLATILE MADV_NONVOLATILE: clear VM_VOLATILE merge vma if possible pte walk to check for pmd_purged()/pte_purged() return any_purged shrink_page_list(): if PageAnon: if try_to_purge_anon(): page_lock_anon_vma_read() anon_vma_interval_tree_foreach: if vma->vm_flags & VM_VOLATILE: lock page table unmap page set_pmd_purged() / set_pte_purged() unlock page table page_lock_anon_vma_read() ... try to reclaim > o Purging logic - when we trigger purging volatile pages to prevent > working set and stop to prevent too excessive purging of volatile > pages > o How to test > Currently, we have a patched jemalloc allocator by Jason's help > although it's not perfect and more rooms to be enhanced but IMO, > it's enough to prove vrange-anonymous. The problem is that > lack of benchmark for testing vrange-file side. I hope that > Mozilla folks can help. > > So its been a while since the last release of the volatile ranges > patches, again. I and John have been busy with other things. > Still, we have been slowly chipping away at issues and differences > trying to get a patchset that we both agree on. > > There's still a few issues, but we figured any further polishing of > the patch series in private would be unproductive and it would be much > better to send the patches out for review and comment and get some wider > opinions. > > You could get full patchset by git > > git clone -b vrange-v10-rc5 --single-branch > git://git.kernel.org/pub/scm/linux/kernel/git/minchan/linux.git > > In v10, there are some notable changes following as > > Whats new in v10: > * Fix several bugs and build break > * Add shmem_purge_page to correct purging shmem/tmpfs > * Replace slab shrinker with direct hooked reclaim path > * Optimize pte scanning by caching previous
Re: [PATCH v2] mtd: block2mtd: Add mutex_destroy
On Sat, Jan 25, 2014 at 10:45:08AM +0800, Fabian Frederick wrote: > mutex_destroy added on each device in block2mtd_exit and add_device failure > > Signed-off-by: Fabian Frederick Pushed to l2-mtd.git/next. Thanks! Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] cgroup: warn if "xattr" is specified with "sane_behavior"
Mount option "xattr" is no longer necessary as it's enabled by default
on kernfs. Warn if "xattr" is specified with "sane_behavior" so that
the option can be removed in the future.
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 2 ++
kernel/cgroup.c| 3 +++
2 files changed, 5 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b6c2652..6fe238e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -262,6 +262,8 @@ enum {
* - "release_agent" and "notify_on_release" are removed.
* Replacement notification mechanism will be implemented.
*
+* - "xattr" mount option is deprecated. kernfs always enables it.
+*
* - cpuset: tasks will be kept in empty cpusets when hotplug happens
* and take masks of ancestors with non-empty cpus/mems, instead of
* being moved to an ancestor.
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e60a5e3..056bd7d 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1265,6 +1265,9 @@ static int parse_cgroupfs_options(char *data, struct
cgroup_sb_opts *opts)
pr_err("cgroup: sane_behavior: clone_children is not
allowed\n");
return -EINVAL;
}
+
+ if (opts->flags & CGRP_ROOT_XATTR)
+ pr_warning("cgroup: sane_behavior: xattr is always
available, flag unnecessary\n");
}
/*
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
