Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done
Hi Peter,
On Thu, Sep 24, 2015 at 2:38 AM, Peter Chen wrote:
> On Wed, Sep 23, 2015 at 01:01:44PM +0100, Felipe F. Tonello wrote:
>> req->actual == req->length means that there is no data left to enqueue,
>> so free the request.
>>
>> Signed-off-by: Felipe F. Tonello
>> ---
>>
>> Changes in v2:
>> * Re enqueue not fully completed requests, instead of read ALSA buffers.
>>
>> drivers/usb/gadget/function/f_midi.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>> b/drivers/usb/gadget/function/f_midi.c
>> index edb84ca..62356cf 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -256,10 +256,12 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
>> *req)
>> /* We received stuff. req is queued again, below */
>> f_midi_handle_out_data(ep, req);
>> } else if (ep == midi->in_ep) {
>> - /* Our transmit completed. See if there's more to go.
>> - * f_midi_transmit eats req, don't queue it again. */
>> - f_midi_transmit(midi, req);
>> - return;
>> + /* Our transmit completed. If there is no more to go,
>> +don't queue it again. */
>> + if (req->actual == req->length) {
>> + free_ep_req(ep, req);
>> + return;
>> + }
>
> I find f_midi_transmit will judge if there are more data, if without
> data, it will free the request.
No. Transmit is called when ALSA trigger is called (whenever
snd_*_read() snd_*_write() is called).
The current code is not crashing anything, but I believe it is just
wrong. It can cause potential problems in future if one is not careful
when doing changes to it.
I would like to send a v3 with free_ep_req().
Felipe
>
> Besides, does one trigger only do one transfer? Sorry, I can't make my
> aplaymidi to receive data, probably due to hardware without midi
> support?
>
> root@imx6qpsabreauto:~# aplaymidi
> ALSA lib
> /var/lib/jenkins/workspace/fido-3.14.28-X11-consolidated_new/temp_build_dir/build_all/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/alsa-lib/1.0.28-r0/alsa-lib-1.0.28/src/seq/seq_hw.c:457:(snd_seq_hw_open)
> open /dev/snd/seq failed: No such file or directory
> Cannot open sequencer - No such file or directory
>
> --
>
> Best Regards,
> Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v6 1/5] pwm: add the Berlin pwm controller driver
On Mon, Sep 21, 2015 at 10:40:08AM +0200, Thierry Reding wrote:
> On Thu, Sep 17, 2015 at 12:13:04PM +0200, Antoine Tenart wrote:
> > +
> > +#define BERLIN_PWM_EN 0x0
> > +#define BERLIN_PWM_CONTROL 0x4
> > +#define BERLIN_PWM_DUTY0x8
> > +#define BERLIN_PWM_TCNT0xc
> > +
> > +#define BERLIN_PWM_ENABLE BIT(0)
> > +#define BERLIN_PWM_INVERT_POLARITY BIT(3)
> > +#define BERLIN_PWM_PRESCALE_MASK 0x7
> > +#define BERLIN_PWM_PRESCALE_MAX4096
> > +#define BERLIN_PWM_MAX_TCNT65535
>
> It'd be nice to see some sort of connection between the register
> definitions and which fields belong to them.
Something like:
#define BERLIN_PWM_EN 0x0
#define BERLIN_PWM_ENABLE BIT(0)
#define BERLIN_PWM_CONTROL 0x4
...
> > +struct berlin_pwm_chip {
> > + struct pwm_chip chip;
> > + struct clk *clk;
> > + void __iomem *base;
> > + spinlock_t lock;
>
> I don't think that lock is necessary here. You have per-channel
> registers and each channel can only be used by one consumer at a time
> anyway.
Sure. I'll make some tests and remove the lock if possible.
> > +#define to_berlin_pwm_chip(chip) \
> > + container_of((chip), struct berlin_pwm_chip, chip)
> > +
> > +#define berlin_pwm_readl(chip, channel, offset)\
> > + readl_relaxed((chip)->base + (channel) * 0x10 + offset)
> > +#define berlin_pwm_writel(val, chip, channel, offset) \
> > + writel_relaxed(val, (chip)->base + (channel) * 0x10 + offset)
>
> These should be static inline functions. Also I think for
> berlin_pwm_writel() val should come after chip and channel to preserve a
> more natural ordering of parameters.
What's the benefit of using static inline functions here?
I'm not convinced having val after chip and channel is more natural, but
this is not a big matter. I'll update.
> > +
> > +/* prescaler table: {1, 4, 8, 16, 64, 256, 1024, 4096} */
> > +static const u32 prescaler_diff_table[] = {
> > + 1, 4, 2, 2, 4, 4, 4, 4,
> > +};
>
> I don't see any relationship between these values and the prescaler
> table given in the comment. Please expand the comment to explain the
> connection.
>
> After reading the remainder of the code, I see that the values in this
> table are the multiplication factors for each of the prescalers. It
> shouldn't be necessary to read the code to find out, so please clarify
> in the comment (and perhaps rename the table to something more related
> to its purpose, such as prescale_factors).
Will do.
> Perhaps an even more easily digestible alternative would be to make this
> a list of prescaler values and then use the values directly to compute
> the number of cycles rather than iteratively dividing and needing this
> unintuitive mapping.
Would something like the following be better?
"""
static const prescaler_table = {1, 4, 8, 16, 64, 256, 1024, 4096};
unsigned int prescale;
u64 tmp;
for (prescale = 0; prescale < ARRAY_SIZE(prescaler_table); prescale++) {
tmp = cycles;
do_div(tmp, prescaler_table[prescale]);
if (tmp <= BERLIN_PWM_MAX_TCNT)
break;
}
if (tmp > BERLIN_PWM_MAX_TCNT)
return -ERANGE;
cycles = tmp;
"""
I personally prefer the prescale factors implementation, but I admit
this is maybe more readable.
> > +
> > + while (cycles > BERLIN_PWM_MAX_TCNT)
> > + do_div(cycles, prescaler_diff_table[++prescale]);
>
> Don't you need to make sure that prescale doesn't exceed the table size?
Sure.
> > +
> > + ret = pwmchip_add(&pwm->chip);
> > + if (ret < 0) {
> > + clk_disable_unprepare(pwm->clk);
>
> Why not enable the clock until after successful registration? It doesn't
> seem like you need access before that. Doing so would introduce a subtle
> race condition between adding the chip (and hence exposing it via sysfs)
> and enabling the clock, so perhaps an even better approach would be to
> add more fine-grained clock management by enabling or disabling it only
> when necessary (clock enables are reference counted, so ->request() and
> ->free() would probably work fine in this case).
>
> This isn't a real objection, though. If you prefer to keep things simple
> the current code is fine with me.
That was the idea. We may update this latter.
> > +static int berlin_pwm_remove(struct platform_device *pdev)
> > +{
> > + struct berlin_pwm_chip *pwm = platform_get_drvdata(pdev);
> > + int ret;
> > +
> > + ret = pwmchip_remove(&pwm->chip);
> > + if (ret)
> > + return ret;
> > +
> > + clk_disable_unprepare(pwm->clk);
>
> You might want to disable the clock regardless. The driver will be
> unloaded regardless of whether pwmchip_remove() returns failure or
> not. The above would leak a clock enable, which may not be what you
> want.
Yes, I'll call clk_disable_unprepare() regardless of what pwmchip_remove()
returns.
Thanks for the review!
Antoine
--
Antoine Ténart, Free Elec
[PATCH] pinctrl: at91-pio4: add PM stuff
Allow GPIOs to be configured as wakeup sources. When going to suspend,
disable all GPIO irqs excepting the one configured as wakeup sources.
Signed-off-by: Ludovic Desroches
---
drivers/pinctrl/pinctrl-at91-pio4.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 6aff632..5e2189f 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -122,6 +123,8 @@ struct atmel_pioctrl {
struct gpio_chip*gpio_chip;
struct irq_domain *irq_domain;
int *irqs;
+ unsigned*pm_wakeup_sources;
+ unsigned*pm_suspend_backup;
struct device *dev;
struct device_node *node;
};
@@ -214,12 +217,35 @@ static void atmel_gpio_irq_unmask(struct irq_data *d)
BIT(pin->line));
}
+#ifdef CONFIG_PM_SLEEP
+
+static int atmel_gpio_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct atmel_pioctrl *atmel_pioctrl = irq_data_get_irq_chip_data(d);
+ int bank = ATMEL_PIO_BANK(d->hwirq);
+ int line = ATMEL_PIO_LINE(d->hwirq);
+
+ /* The gpio controller has one interrupt line per bank. */
+ irq_set_irq_wake(atmel_pioctrl->irqs[bank], on);
+
+ if (on)
+ atmel_pioctrl->pm_wakeup_sources[bank] |= BIT(line);
+ else
+ atmel_pioctrl->pm_wakeup_sources[bank] &= ~(BIT(line));
+
+ return 0;
+}
+#else
+#define atmel_gpio_irq_set_wake NULL
+#endif /* CONFIG_PM_SLEEP */
+
static struct irq_chip atmel_gpio_irq_chip = {
.name = "GPIO",
.irq_ack= atmel_gpio_irq_ack,
.irq_mask = atmel_gpio_irq_mask,
.irq_unmask = atmel_gpio_irq_unmask,
.irq_set_type = atmel_gpio_irq_set_type,
+ .irq_set_wake = atmel_gpio_irq_set_wake,
};
static void atmel_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
@@ -792,6 +818,43 @@ static struct pinctrl_desc atmel_pinctrl_desc = {
.pmxops = &atmel_pmxops,
};
+static int atmel_pctrl_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct atmel_pioctrl *atmel_pioctrl = platform_get_drvdata(pdev);
+ int i;
+
+ /*
+* For each bank, save IMR to restore it later and disable all GPIO
+* interrupts excepting the ones marked as wakeup sources.
+*/
+ for (i = 0; i < atmel_pioctrl->nbanks; i++) {
+ atmel_pioctrl->pm_suspend_backup[i] =
+ atmel_gpio_read(atmel_pioctrl, i, ATMEL_PIO_IMR);
+ atmel_gpio_write(atmel_pioctrl, i, ATMEL_PIO_IDR,
+~atmel_pioctrl->pm_wakeup_sources[i]);
+ }
+
+ return 0;
+}
+
+static int atmel_pctrl_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct atmel_pioctrl *atmel_pioctrl = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < atmel_pioctrl->nbanks; i++)
+ atmel_gpio_write(atmel_pioctrl, i, ATMEL_PIO_IER,
+atmel_pioctrl->pm_suspend_backup[i]);
+
+ return 0;
+}
+
+static const struct dev_pm_ops atmel_pctrl_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(atmel_pctrl_suspend, atmel_pctrl_resume)
+};
+
/*
* The number of banks can be different from a SoC to another one.
* We can have up to 16 banks.
@@ -908,6 +971,18 @@ static int atmel_pinctrl_probe(struct platform_device
*pdev)
atmel_pioctrl->gpio_chip->dev = dev;
atmel_pioctrl->gpio_chip->names = atmel_pioctrl->group_names;
+ atmel_pioctrl->pm_wakeup_sources = devm_kzalloc(dev,
+ sizeof(*atmel_pioctrl->pm_wakeup_sources)
+ * atmel_pioctrl->nbanks, GFP_KERNEL);
+ if (!atmel_pioctrl->pm_wakeup_sources)
+ return -ENOMEM;
+
+ atmel_pioctrl->pm_suspend_backup = devm_kzalloc(dev,
+ sizeof(*atmel_pioctrl->pm_suspend_backup)
+ * atmel_pioctrl->nbanks, GFP_KERNEL);
+ if (!atmel_pioctrl->pm_suspend_backup)
+ return -ENOMEM;
+
atmel_pioctrl->irqs = devm_kzalloc(dev, sizeof(*atmel_pioctrl->irqs)
* atmel_pioctrl->nbanks, GFP_KERNEL);
if (!atmel_pioctrl->irqs)
@@ -1006,6 +1081,7 @@ static struct platform_driver atmel_pinctrl_driver = {
.driver = {
.name = "pinctrl-at91-pio4",
.of_match_table = atmel_pctrl_of_match,
+ .pm = &atmel_pctrl_pm_ops,
},
.probe = atmel_pinctrl_probe,
.remove = atmel_pinctrl_remove,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
[RESEND PATCH] sched: consider missed ticks when updating global cpu load
From: Byungchul Park
hello,
i have already sent this patch about 1 month ago.
(see https://lkml.org/lkml/2015/8/13/160)
now, i am resending the same patch with adding some additional commit
message.
thank you,
byungchul
->8-
>From 8ece9a0482e74a39cd2e9165bf8eec1d04665fa9 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Fri, 25 Sep 2015 17:10:10 +0900
Subject: [RESEND PATCH] sched: consider missed ticks when updating global cpu
load
in hrtimer_interrupt(), the first tick_program_event() can be failed
because the next timer could be already expired due to,
(see the comment in hrtimer_interrupt())
- tracing
- long lasting callbacks
- being scheduled away when running in a VM
in the case that the first tick_program_event() is failed, the second
tick_program_event() set the expired time to more than one tick later.
then next tick can happen after more than one tick, even though tick is
not stopped by e.g. NOHZ.
when the next tick occurs, update_process_times() -> scheduler_tick()
-> update_cpu_load_active() is performed, assuming the distance between
last tick and current tick is 1 tick! it's wrong in this case. thus,
this abnormal case should be considered in update_cpu_load_active().
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4d5f97b..829282f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4356,12 +4356,15 @@ void update_cpu_load_nohz(void)
*/
void update_cpu_load_active(struct rq *this_rq)
{
+ unsigned long curr_jiffies = READ_ONCE(jiffies);
+ unsigned long pending_updates;
unsigned long load = weighted_cpuload(cpu_of(this_rq));
/*
* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
*/
- this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, load, 1);
+ pending_updates = curr_jiffies - this_rq->last_load_update_tick;
+ this_rq->last_load_update_tick = curr_jiffies;
+ __update_cpu_load(this_rq, load, pending_updates);
}
/*
--
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/
Voltage setting on chained regulators, how?
Hi, On i.MX6 we have the situation that the CPU is supplied by a SoC internal linear regulator which in turn is supplied by an external switching regulator: ---> Switching regulator ---> LDO ---> CPU For energy efficiency reasons we want to minimize the dropout voltage on the LDO. Any idea how such a scenario could be implemented? The regulator framework already has some idea of supply regulators, but it only takes care of en/disabling the supplies and will not change the voltage on the supplies. Should this be implemented in the regulator framework? Some first experiments brought me into a locking hell quite fast. Another possibility of course would be to implement this completely in the cpufreq driver and not bother the regulator framework. Looking at drivers/cpufreq/imx6q-cpufreq.c the regulator handling code in there is already complicated enough since in reality it's not one LDO but three and we would have to add another two regulators to this driver. For added fun ideally we want to put the LDOs in bypass mode instead of configuring them for minimum dropout. The bypass mode doesn't work for the 1.2GHz operating point though since the ripple on the switching regulator gets too high. So we can't just statically configure bypass mode but have to enable it dynamically based on the operating points. Any ideas/input how to proceed? Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] usb: gadget: f_midi: free request when usb_ep_queue fails
On Fri, Sep 25, 2015 at 09:27:49AM +0100, Felipe Tonello wrote:
> On Thu, Sep 24, 2015 at 2:20 AM, Peter Chen wrote:
> > On Wed, Sep 23, 2015 at 12:40:46PM +0100, Felipe Tonello wrote:
> >> Hi Peter,
> >>
> >> On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen
> >> wrote:
> >> > On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
> >> >> This fix a memory leak that will occur in this case.
> >> >>
> >> >> Signed-off-by: Felipe F. Tonello
> >> >> ---
> >> >> drivers/usb/gadget/function/f_midi.c | 4 +++-
> >> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/usb/gadget/function/f_midi.c
> >> >> b/drivers/usb/gadget/function/f_midi.c
> >> >> index e92aff5..e6a114b 100644
> >> >> --- a/drivers/usb/gadget/function/f_midi.c
> >> >> +++ b/drivers/usb/gadget/function/f_midi.c
> >> >> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi,
> >> >> struct usb_request *req)
> >> >> int err;
> >> >>
> >> >> err = usb_ep_queue(ep, req, GFP_ATOMIC);
> >> >> - if (err < 0)
> >> >> + if (err < 0) {
> >> >> ERROR(midi, "%s queue req: %d\n",
> >> >> midi->in_ep->name, err);
> >> >> + free_ep_req(ep, req);
> >> >> + }
> >> >> } else {
> >> >> free_ep_req(ep, req);
> >> >> }
> >> >> --
> >> >> 2.1.4
> >> >>
> >> >
> >> > I may know your problem, current midi library, alsa and this driver
> >> > allow device sends as much data as possible, but without block the
> >> > sending until host reads data, it only allocates the request buffer
> >> > (using midi_alloc_ep_req), but without free, so after you send
> >> > enough data, it is out of memory.
> >>
> >> Yes. Also there is the case where the usb cable is not conected, thus
> >> failing to hardware enqueue the request, causing a memory leak on this
> >> request.
> >>
> >
> > If the usb cable is not connected, the related endpoints should be
> > not enabled. Would you really observe enqueue the request without
> > cable connected?
>
> The usb_ep_queue() returns an error if it is not connected, causing
> the request never to be freed and never to be queued. Thus a memory
> leak happens.
>
If it is not connected, the ep is not enabled, why we will call
usb_ep_queue? If it really does, there must be something wrong.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] usb: chipidea: core: fix when building without CONFIG_PM support
On Fri, Sep 25, 2015 at 09:26:21AM +0100, Felipe Tonello wrote: > Hi Peter, > > On Thu, Sep 24, 2015 at 2:17 AM, Peter Chen wrote: > > On Wed, Sep 23, 2015 at 12:56:58PM +0100, Felipe F. Tonello wrote: > >> If CONFIG_PM or CONFIG_PM_SLEEP is not set, driver will not compile > >> properly. > >> > > > > Would you post the warning or error messages? > > > > I just tried at v4.3-rc1 (v4.2 should be same), without any problems. > > Actually I tested again with the latest and it doesn't break. But > still I believe it is the right thing to do, even though it builds. > Just good practice to make sure the ifdefs are correct on driver code. > We need to decrease #ifdefs as less as possible, only add it if it really needs. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: error when make pdfdocs
2015-09-25 4:40 GMT+08:00 Jim Davis : > On Fri, Sep 18, 2015 at 7:35 AM, 慕冬亮 wrote: >> I git clone and git pull the latest linux kernel. >> When I make pdfdocs, it reports the following error to me. >> But I checked the filesystems.xml:14946, no error found. >> >> --- >> PDF Documentation/DocBook/filesystems.pdf >> Using catalogs: /etc/sgml/catalog >> Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print >> Working on: /home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml >> openjade:/home/mdl/Repos/linux/Documentation/DocBook/filesystems.xml:14946:16:E: > > The last time I tried (and failed) to get make pdfdocs to work it > seemed to depend in very sensitive ways on the xml converter being > used, among other issues, so if it's bombing with openjade you might > see if there are alternatives you can try. See > https://www.mail-archive.com/kernelnewbies%40kernelnewbies.org/msg14306.html > for some of the painful details. I did checkout linux-stable : linux-4.1.y, linux 4.2.y and master. However, I always failed to generate pdf docs. I have given up generating pdf of Document. I can "make mandocs" to generate man pages.It is the same content with pdf. - mudongliang > > -- > Jim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] net/ibm/emac: bump version numbers for correct work with ethtool
On Thu, 24 Sep 2015 22:53:03 -0700 (PDT) "David Miller" wrote: > From: Ivan Mikhaylov > Date: Fri, 25 Sep 2015 08:07:52 +0400 > > > Ben proposed one, is it eligible? > > Need I resubmit patch with sign and detailed description? > > If I genuinely need to answer that question, maybe you should sit back > for a little while and think about it yourself, ok? Sorry, for those stupid questions. David, Ben, thanks for the help. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] cgroup: fix seq_show_option merge with legacy_name
On Thu, Sep 24, 2015 at 11:35:00AM -0700, Kees Cook wrote:
> On Thu, Sep 24, 2015 at 11:33 AM, Luis Henriques
> wrote:
> > On Tue, Sep 08, 2015 at 11:30:43AM -0700, Kees Cook wrote:
> >> When seq_show_option (068acf2ee776) was merged, it did not correctly
> >> collide with cgroup's addition of legacy_name (3e1d2eed39d8) changes. This
> >> fixes the reported name.
> >>
> >
> > Since a068acf2ee77 ("fs: create and use seq_show_option for escaping")
> > has been CC'ed to stable, shouldn't this be tagged to stable too?
> >
> > (This is upstream commit 61e57c0c3a37 "cgroup: fix seq_show_option
> > merge with legacy_name".)
>
> If the cgroup change when to stable also, then yes.
>
And this didn't happen, so no need to include this commit. Sorry for the
noise.
Cheers,
--
Luís
> -Kees
>
> >
> > Cheers,
> > --
> > Luís
> >
> >> Signed-off-by: Kees Cook
> >> ---
> >> kernel/cgroup.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> >> index a8538e443784..2cf0f79f1fc9 100644
> >> --- a/kernel/cgroup.c
> >> +++ b/kernel/cgroup.c
> >> @@ -1342,7 +1342,7 @@ static int cgroup_show_options(struct seq_file *seq,
> >> if (root != &cgrp_dfl_root)
> >> for_each_subsys(ss, ssid)
> >> if (root->subsys_mask & (1 << ssid))
> >> - seq_show_option(seq, ss->name, NULL);
> >> + seq_show_option(seq, ss->legacy_name, NULL);
> >> if (root->flags & CGRP_ROOT_NOPREFIX)
> >> seq_puts(seq, ",noprefix");
> >> if (root->flags & CGRP_ROOT_XATTR)
> >> --
> >> 1.9.1
> >>
> >>
> >> --
> >> Kees Cook
> >> Chrome OS Security
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> --
> Kees Cook
> Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v1] usb: dwc2: gadget: fix a memory use-after-free bug
> -Original Message- > From: Kaukab, Yousaf > Sent: Tuesday, September 22, 2015 2:24 PM > To: John Youn; Yunzhi Li; Felipe Balbi > Cc: he...@sntech.de; c...@rock-chips.com; h...@rock-chips.com; yk@rock- > chips.com; gaura...@google.com; albe...@google.com; w...@rock-chips.com; > jwer...@chromium.org; jeffy.c...@rock-chips.com; Herrero, Gregory; > huang...@rock-chips.com; rockchip-disc...@chromium.org; Greg Kroah- > Hartman; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH v1] usb: dwc2: gadget: fix a memory use-after-free bug > > > -Original Message- > > From: John Youn [mailto:john.y...@synopsys.com] > > Sent: Thursday, June 11, 2015 4:16 AM > > To: Yunzhi Li; john.y...@synopsys.com > > Cc: he...@sntech.de; c...@rock-chips.com; h...@rock-chips.com; yk@rock- > > chips.com; gaura...@google.com; albe...@google.com; > > w...@rock-chips.com; jwer...@chromium.org; jeffy.c...@rock-chips.com; > > Herrero, Gregory; Kaukab, Yousaf; huang...@rock-chips.com; > > rockchip-disc...@chromium.org; Greg Kroah-Hartman; > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH v1] usb: dwc2: gadget: fix a memory use-after-free > > bug > > > > On 5/28/2015 10:22 PM, Yunzhi Li wrote: > > > When s3c_hsotg_handle_unaligned_buf_complete() hs_req->req.buf > > > already destroyed, in s3c_hsotg_unmap_dma(), it touches > > > hs_req->req.dma again, so s3c_hsotg_unmap_dma() should be called > > > before s3c_hsotg_handle_unaligned_buf_complete(). Otherwise, it will > > > cause a bad_page BUG, when allocate this memory page next time. > > > > > > This bug led to the following crash: > > > > > > BUG: Bad page state in process swapper/0 pfn:2bdbc > > > [ 26.820440] page:eed76780 count:0 mapcount:0 mapping: (null) > index:0x0 > > > [ 26.854710] page flags: 0x200(arch_1) > > > [ 26.885836] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag > set > > > [ 26.919179] bad because of flags: > > > [ 26.948917] page flags: 0x200(arch_1) > > > [ 26.979100] Modules linked in: > > > [ 27.008401] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W3.14.0 #17 > > > [ 27.041816] [] (unwind_backtrace) from [] > > (show_stack+0x20/0x24) > > > [ 27.076108] [] (show_stack) from [] > > (dump_stack+0x70/0x8c) > > > [ 27.110246] [] (dump_stack) from [] > > (bad_page+0xfc/0x12c) > > > [ 27.143958] [] (bad_page) from [] > > (get_page_from_freelist+0x3e4/0x50c) > > > [ 27.179298] [] (get_page_from_freelist) from [] > > (__alloc_pages_nodemask) > > > [ 27.216296] [] (__alloc_pages_nodemask) from [] > > (__get_free_pages+0x20/) > > > [ 27.252326] [] (__get_free_pages) from [] > > (kmalloc_order_trace+0x34/0xa) > > > [ 27.288295] [] (kmalloc_order_trace) from [] > > (__kmalloc+0x40/0x1ac) > > > [ 27.323751] [] (__kmalloc) from [] > > (s3c_hsotg_ep_queue.isra.12+0x7c/0x1) > > > [ 27.359937] [] (s3c_hsotg_ep_queue.isra.12) from > [] > > (s3c_hsotg_ep_queue) > > > [ 27.397478] [] (s3c_hsotg_ep_queue_lock) from [] > > (rx_submit+0xfc/0x164) > > > [ 27.433619] [] (rx_submit) from [] > > (rx_complete+0x22c/0x230) > > > [ 27.468872] [] (rx_complete) from [] > > (s3c_hsotg_complete_request+0xfc/0) > > > [ 27.506240] [] (s3c_hsotg_complete_request) from > > [] (s3c_hsotg_handle_o) > > > [ 27.545401] [] (s3c_hsotg_handle_outdone) from > [] > > (s3c_hsotg_epint+0x2c) > > > [ 27.583689] [] (s3c_hsotg_epint) from [] > > (s3c_hsotg_irq+0x1dc/0x4ac) > > > [ 27.621041] [] (s3c_hsotg_irq) from [] > > (handle_irq_event_percpu+0x70/0x) > > > [ 27.659066] [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x4c) > > > [ 27.697322] [] (handle_irq_event) from [] > > (handle_fasteoi_irq+0xc8/0x11) > > > [ 27.735451] [] (handle_fasteoi_irq) from [] > > (generic_handle_irq+0x30/0x) > > > [ 27.773918] [] (generic_handle_irq) from [] > > (__handle_domain_irq+0x84/0) > > > [ 27.812018] [] (__handle_domain_irq) from [] > > (gic_handle_irq+0x48/0x6c) > > > [ 27.849695] [] (gic_handle_irq) from [] > > (__irq_svc+0x40/0x50) > > > [ 27.886907] Exception stack(0xc0d01ee0 to 0xc0d01f28) > > > > > > Signed-off-by: Yunzhi Li > > > > > > --- > > > > > > drivers/usb/dwc2/gadget.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > > > index 6a30887..8070602 100644 > > > --- a/drivers/usb/dwc2/gadget.c > > > +++ b/drivers/usb/dwc2/gadget.c > > > @@ -1389,14 +1389,14 @@ static void > > > s3c_hsotg_complete_request(struct > > dwc2_hsotg *hsotg, > > > if (hs_req->req.status == -EINPROGRESS) > > > hs_req->req.status = result; > > > > > > + if (using_dma(hsotg)) > > > + s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > > > + > > > s3c_hsotg_handle_unaligned_buf_complete(hsotg, hs_ep, > > hs_req); > > > > > > hs_ep->req = NULL; > > > list_del_init(&hs_req->queue); > > > > > > - if (using_dma(hsotg)) > > > - s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > > > -
[PATCH v2] net/ibm/emac: bump version numbers for correct work with ethtool
The size of the MAC register dump used to be the size specified by the
reg property in the device tree. Userland has no good way of finding
out that size, and it was not specified consistently for each MAC type,
so ethtool would end up printing junk at the end of the register dump
if the device tree didn't match the size it assumed.
Using the new version numbers indicates unambiguously that the size of
the MAC register dump is dependent only on the MAC type.
Fixes: 5369c71f7ca2 ("net/ibm/emac: fix size of emac dump memory areas")
Signed-off-by: Ivan Mikhaylov
---
drivers/net/ethernet/ibm/emac/core.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.h
b/drivers/net/ethernet/ibm/emac/core.h
index 28df374..ac02c67 100644
--- a/drivers/net/ethernet/ibm/emac/core.h
+++ b/drivers/net/ethernet/ibm/emac/core.h
@@ -460,8 +460,8 @@ struct emac_ethtool_regs_subhdr {
u32 index;
};
-#define EMAC_ETHTOOL_REGS_VER 0
-#define EMAC4_ETHTOOL_REGS_VER 1
-#define EMAC4SYNC_ETHTOOL_REGS_VER 2
+#define EMAC_ETHTOOL_REGS_VER 3
+#define EMAC4_ETHTOOL_REGS_VER 4
+#define EMAC4SYNC_ETHTOOL_REGS_VER 5
#endif /* __IBM_NEWEMAC_CORE_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
On Fri, Sep 25, 2015 at 05:47:13PM +0900, Minchan Kim wrote: > On Fri, Sep 25, 2015 at 10:17:54AM +0200, Vitaly Wool wrote: > > > > > I already said questions, opinion and concerns but anything is not clear > > > until now. Only clear thing I could hear is just "compaction stats are > > > better" which is not enough for me. Sorry. > > > > > > 1) https://lkml.org/lkml/2015/9/15/33 > > > 2) https://lkml.org/lkml/2015/9/21/2 > > > > Could you please stop perverting the facts, I did answer to that: > > https://lkml.org/lkml/2015/9/21/753. > > > > Apart from that, an opinion is not necessarily something I would > > answer. Concerns about zsmalloc are not in the scope of this patch's > > discussion. If you have any concerns regarding this particular patch, > > please let us know. > > Yes, I don't want to interrupt zbud thing which is Seth should maintain > and I respect his decision but the reason I nacked is you said this patch > aims for supporing zbud into zsmalloc for determinism. zram Sorry for the typo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No more new fbdev drivers, please
Hi, On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote: > fbdev is (more or less) maintained, but it's a deprecated framework. All > new Linux display drivers should be done on DRM. > > So let's not add any more new fbdev drivers. > > I will continue to maintain the current fbdev drivers, and I don't mind > adding some new features to those current drivers, as long as the amount > of code required to add the features stays sensible. > > I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, > and the question is what to do with those. I was still planning to work on xgifb as I need it on some systems for the console. A. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()
On Fri, Sep 25, 2015 at 7:58 AM, Sedat Dilek wrote: > On Thu, Sep 24, 2015 at 8:00 PM, David Miller wrote: >> From: Sedat Dilek >> Date: Thu, 24 Sep 2015 18:19:16 +0200 >> >>> OK, I guess DaveM will take your patch into net.git#master first... >>> and tag it there with CC-stable? >> >> I do not tag anything with stable. >> >> I queue it up into a patchwork bundle and explicitly submit those >> patches to sta...@vger.kernel.org at a time of my own choosing. >> >> This is a FAQ, documented in the kernel Documentation/ subdirectory. > > OK, so this is a special handling for netdev? > I normally look at "SubmittingPatches" documentation [1] and looked in > this case especially at [2]. > Can you point me to this "FAQ"? > OK, I found it by myself. [ Documentation/stable_kernel_rules.txt ] "Procedure for submitting patches to the -stable tree: - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.txt" [ Documentation/networking/netdev-FAQ.txt ] "Q: I have created a network patch and I think it should be backported to stable. Should I add a "Cc: sta...@vger.kernel.org" like the references in the kernel's Documentation/ directory say? A: No. See above answer. In short, if you think it really belongs in stable, then ensure you write a decent commit log that describes who gets impacted by the bugfix and how it manifests itself, and when the bug was introduced. If you do that properly, then the commit will get handled appropriately and most likely get put in the patchworks stable queue if it really warrants it. If you think there is some valid information relating to it being in stable that does _not_ belong in the commit log, then use the three dash marker line as described in Documentation/SubmittingPatches to temporarily embed that information into the patch that you send." [3] collects all netdev "stable" patches. I hope I remember that for the next time dealing with such issues. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_kernel_rules.txt#n30 [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.txt#n155 [3] http://patchwork.ozlabs.org/bundle/davem/stable/?state=* > Where do you include Guillaume's patch - in net.git#master? > > Since Linux v4.2 my Internet connection via UMTS/HSPA USB modem is "unstable". > For me this is an important fix. > > Thanks. > > - Sedat - > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches > [2] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n297 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] zbud: allow up to PAGE_SIZE allocations
On Fri, Sep 25, 2015 at 10:17:54AM +0200, Vitaly Wool wrote: > > > I already said questions, opinion and concerns but anything is not clear > > until now. Only clear thing I could hear is just "compaction stats are > > better" which is not enough for me. Sorry. > > > > 1) https://lkml.org/lkml/2015/9/15/33 > > 2) https://lkml.org/lkml/2015/9/21/2 > > Could you please stop perverting the facts, I did answer to that: > https://lkml.org/lkml/2015/9/21/753. > > Apart from that, an opinion is not necessarily something I would > answer. Concerns about zsmalloc are not in the scope of this patch's > discussion. If you have any concerns regarding this particular patch, > please let us know. Yes, I don't want to interrupt zbud thing which is Seth should maintain and I respect his decision but the reason I nacked is you said this patch aims for supporing zbud into zsmalloc for determinism. For that, at least, you should discuss with me and Sergey but I feel you are ignoring our comments. > > > Vitally, Please say what's the root cause of your problem and if it > > is external fragmentation, what's the problem of my approach? > > > > 1) make non-LRU page migrate > > 2) provide zsmalloc's migratpage > > The problem with your approach is that in your world I need to prove > my right to use zbud. This is a very strange speculation. No. If you want to contribute something, you should prove why yours is better. I already said my concerns and my approach. It's your turn that you should explain why it's better. > > > We should provide it for CMA as well as external fragmentation. > > I think we could solve your issue with above approach and > > it fundamentally makes zsmalloc/zbud happy in future. > > I doubt that but I'll answer in this thread: > https://lkml.org/lkml/2015/9/15/33 as zsmalloc deficiencies do not > have direct relation to this particular patch. > > > Also, please keep it in mind that zram has been in linux kernel for > > memory efficiency for a long time and later zswap/zbud was born > > for *determinism* at the cost of memory efficiency. > > Yep, and determinism is more important to me than the memory > efficiency. Dropping the compression ration from 3.2x to 1.8x is okay > with me and stalls in UI are not. Then, you could use zswap which have aimed for it with small changes to prevent writeback. > > ~vitaly -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] scsi: provide UAPI version of scsi/sg.h and scsi/scsi_ioctl.h
On 17/09/2015 17:32, Bart Van Assche wrote: > >> + >> +#ifndef __KERNEL__ >> +/* Keep in sync with SG_DEFAULT_TIMEOUT of scsi/sg.h */ >> #define SG_DEFAULT_TIMEOUT(60*HZ) /* HZ == 'jiffies in 1 >> second' */ >> #endif > > Is it useful and/or necessary to export this constant ? To me this looks > like an implementation aspect rather than an aspect of the scsi-sg API. That's fine, I can remove it. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 RFC v2] pidns: introduce syscall getvpid
On 09/24/2015 09:53 PM, Konstantin Khlebnikov wrote:
pid_t getvpid(pid_t pid, int source, int target);
This syscall converts pid from source pid-namespace into pid in target
pid-namespace. Namespaces are defined by file descriptors pointing to
namespace entries in proc (/proc/[pid]/ns/pid). If source / target is
negative then current pid namespace is used.
If pid is negative then getvpid() returns pid of parent task for -pid.
If pid is unreachable from target namespace then syscall returns zero.
Errors:
ESRCHtask not found
EBADFclosed file descriptor
EINVAL not pid-namespace file descriptor
Examples:
getvpid(pid, ns, -1) -> pid in our pid namespace
getvpid(pid, -1, ns) -> pid in container
getvpid(1, ns1, ns2) > 0 -> ns1 inside ns2
getvpid(1, ns1, ns2) == 0 -> ns1 outside ns2
getvpid(1, ns, -1)-> init task of pid-namespace
getvpid(-1, ns, -1) -> task in parent pid-namespace
getvpid(-pid, -1, -1) -> get ppid by pid
Signed-off-by: Konstantin Khlebnikov
---
v2:
* use namespace-fd as second/third argument
* add -pid for getting parent pid
* move code into kernel/sys.c next to getppid
* drop ifdef CONFIG_PID_NS
* add generic syscall
---
arch/x86/entry/syscalls/syscall_32.tbl |1 +
arch/x86/entry/syscalls/syscall_64.tbl |1 +
include/linux/syscalls.h |1 +
include/uapi/asm-generic/unistd.h |4 ++
kernel/sys.c | 63
5 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
b/arch/x86/entry/syscalls/syscall_32.tbl
index 7663c455b9f6..dadb55d42fc9 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -382,3 +382,4 @@
373 i386shutdownsys_shutdown
374 i386userfaultfd sys_userfaultfd
375 i386membarrier sys_membarrier
+376i386getvpid sys_getvpid
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
b/arch/x86/entry/syscalls/syscall_64.tbl
index 278842fdf1f6..0338f2eb3b7c 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -331,6 +331,7 @@
322 64 execveatstub_execveat
323 common userfaultfd sys_userfaultfd
324 common membarrier sys_membarrier
+325common getvpid sys_getvpid
#
# x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a460e2ef2843..01ac603c8b5c 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -222,6 +222,7 @@ asmlinkage long sys_nanosleep(struct timespec __user *rqtp,
struct timespec __us
asmlinkage long sys_alarm(unsigned int seconds);
asmlinkage long sys_getpid(void);
asmlinkage long sys_getppid(void);
+asmlinkage long sys_getvpid(pid_t pid, int source, int target);
asmlinkage long sys_getuid(void);
asmlinkage long sys_geteuid(void);
asmlinkage long sys_getgid(void);
diff --git a/include/uapi/asm-generic/unistd.h
b/include/uapi/asm-generic/unistd.h
index 8da542a2874d..163df44b23cf 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -711,9 +711,11 @@ __SYSCALL(__NR_bpf, sys_bpf)
__SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat)
#define __NR_membarrier 282
__SYSCALL(__NR_membarrier, sys_membarrier)
+#define __NR_getvpid 283
+__SYSCALL(__NR_getvpid, sys_getvpid)
#undef __NR_syscalls
-#define __NR_syscalls 283
+#define __NR_syscalls 284
/*
* All syscalls below here should go away really,
diff --git a/kernel/sys.c b/kernel/sys.c
index fa2f2f671a5c..fbfe938dd9d7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
@@ -855,6 +856,68 @@ SYSCALL_DEFINE0(getppid)
return pid;
}
+SYSCALL_DEFINE3(getvpid, pid_t, pid, int, source, int, target)
+{
+ struct file *source_file = NULL, *target_file = NULL;
+ struct pid_namespace *source_ns, *target_ns;
+ struct pid *struct_pid;
+ struct ns_common *ns;
+ pid_t result;
+
+ if (source >= 0) {
+ source_file = proc_ns_fget(source);
+ result = PTR_ERR(source_file);
+ if (IS_ERR(source_file))
+ goto out;
+ ns = get_proc_ns(file_inode(source_file));
+ result = -EINVAL;
+ if (ns->ops->type != CLONE_NEWPID)
+ goto out;
+ source_ns = container_of(ns, struct pid_namespace, ns);
+ } else
+ source_ns = task_active_pid_ns(current);
+
+ if (target >= 0) {
+ target_file = proc_ns_fget(target);
+ result = PTR_ERR(target_file);
+ if (IS_ERR(target_file))
+ goto out;
+ ns =
RE: [PATCH 00/12] mtd: nand_bbt: introduce independent nand BBT
Hi Boris, Sorry for trouble you. Since I cannot send mail using 'git send-email' right now. I sent this series by outlook. Thanks for your suggestion. I'll fix this soon. Peter Pan On Fri, 25 Sep 2015 14:54:38 + Boris Brezillon < boris.brezil...@free-electrons.com > wrote: > Hi Peter, > > This comment is not related to the code itself, but next time you send a > patch series, could you send all patches as a reply to the cover letter? > This is automatically done when you use git send-email unless you pass > the --no-thread option. > The following command should do the trick: > > git send-email /*.patch > > Best Regards, > > Boris > > On Fri, 25 Sep 2015 06:34:34 + > Peter Pan 潘栋 (peterpandong) wrote: > > > Currently nand_bbt.c is tied with struct nand_chip, and it makes other > > NAND family chips hard to use nand_bbt.c. Maybe it's the reason why > > onenand has own bbt(onenand_bbt.c). > > > > Separate struct nand_chip from BBT code can make current BBT shareable. > > We create struct nand_bbt to take place of nand_chip in nand_bbt.c. > > Struct nand_bbt contains all the information BBT needed from outside and > > it should be embedded into NAND family chip struct (such as struct > nand_chip). > > NAND family driver should allocate, initialize and free struct nand_bbt. > > > > Below is mtd folder structure we want: > > mtd > > ├── Kconfig > > ├── Makefile > > ├── ... > > ├── nand_bbt.c > > ├── nand > > │ ├── Kconfig > > │ ├── Makefile > > │ ├── nand_base.c > > │ ├── nand_ids.c > > │ ├── ... > > │ └── xway_nand.c > > ├── spi-nand > > │ ├── Kconfig > > │ ├── Makefile > > │ ├── spi-nand-base.c > > │ ├── ... > > │ └── spi-nand-device.c > > └── ... > > > > Most of the patch is borrowed from Brian Norris > . > > > http://git.infradead.org/users/norris/linux-mtd.git/shortlog/refs/heads/nan > d-bbt > > Based on Brian's suggestion, I make my previous BBT patch into 12 > independent > > patches. Previous patch is http://patchwork.ozlabs.org/patch/492066/ > > Beside the patch split, I also moved nand_bbt.c to mtd folder, which didn't > in > > previous patch. > > > > Patch 3, 7, 8, 9, 10 and 11 are totally borrowed from Brian's git tree. I > > just > > test and split the code into independent patch. Patch 1, 2, 5 and 6 are > partial > > borrowed. I make some changes from Brian's git tree and the changes are > recorded > > in commit log. Patch 4 and 12 are written by me. > > > > The patch is tested on Zed board. This version of this series is based on > master > > branch of l2-mtd.git (commit > e1305df1283cbe1aa57093f8766b2dfe650ed5ff). > > > > Brian Norris (6): > > mtd: nand_bbt: add new API definitions > > mtd: nand: make nand_erase_nand() static > > mtd: nand_bbt: remove struct nand_chip from nand_bbt.c > > mtd: nand_bbt: remove old API definitions > > mtd: nand_bbt: remove NAND_BBT_DYNAMICSTRUCT macro > > mtd: nand: remove nand_chip.bbt > > Brian Norris and Peter Pan (4): > > mtd: nand_bbt: new header for nand family BBT > > mtd: nand_bbt: introduce struct nand_bbt > > mtd: nand: use new BBT API instead of old ones > > mtd: nand_bbt: use erase() and is_bad_bbm() hook in BBT > > Peter Pan (2): > > mtd: nand_bbt: add nand_bbt_markbad_factory() interface > > mtd: nand-bbt: move nand_bbt.c to mtd folder > > > > --- > > drivers/mtd/Kconfig |7 + > > drivers/mtd/Makefile |1 + > > drivers/mtd/nand/Kconfig |2 +- > > drivers/mtd/nand/Makefile|2 +- > > drivers/mtd/nand/docg4.c |6 +- > > drivers/mtd/nand/nand_base.c | 145 - > > drivers/mtd/nand/nand_bbt.c | 1377 > > -- > > drivers/mtd/nand_bbt.c | 1289 > +++ > > include/linux/mtd/bbm.h | 96 +-- > > include/linux/mtd/nand.h | 16 +- > > include/linux/mtd/nand_bbt.h | 177 ++ > > 11 files changed, 1624 insertions(+), 1494 deletions(-) > > delete mode 100644 drivers/mtd/nand/nand_bbt.c > > create mode 100644 drivers/mtd/nand_bbt.c > > create mode 100644 include/linux/mtd/nand_bbt.h > > > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
RE: [PATCH 01/12] mtd: nand_bbt: new header for nand family BBT
Sorry for send the patch 1 twice.
Since I cannot send mail using 'git send-email' right now. I send this series
by outlook. This may cause copyright symbol wrong. Patch 1 and 12 got this
problem and patch 12 cannot be applied. Please ignore this error.
Peter Pan
On Fri, 25 Sep 2015 14:37:35 +
Peter Pan 潘栋 (peterpandong) wrote:
> Migrating existing BBT definitions from bbm.h to nand_bbt.h
>
> Signed-off-by: Brian Norris
> [Peter: correct misspelling. s/neccecary/necessary/]
> Signed-off-by: Peter Pan
> ---
> include/linux/mtd/bbm.h | 96 +--
> include/linux/mtd/nand_bbt.h | 118
> +++
> 2 files changed, 119 insertions(+), 95 deletions(-)
> create mode 100644 include/linux/mtd/nand_bbt.h
>
> diff --git a/include/linux/mtd/bbm.h b/include/linux/mtd/bbm.h
> index 36bb6a5..fb751d9 100644
> --- a/include/linux/mtd/bbm.h
> +++ b/include/linux/mtd/bbm.h
> @@ -28,102 +28,8 @@
> #ifndef __LINUX_MTD_BBM_H
> #define __LINUX_MTD_BBM_H
>
> -/* The maximum number of NAND chips in an array */
> -#define NAND_MAX_CHIPS 8
> +#include
>
> -/**
> - * struct nand_bbt_descr - bad block table descriptor
> - * @options: options for this descriptor
> - * @pages: the page(s) where we find the bbt, used with option
> BBT_ABSPAGE
> - * when bbt is searched, then we store the found bbts pages here.
> - * Its an array and supports up to 8 chips now
> - * @offs:offset of the pattern in the oob area of the page
> - * @veroffs: offset of the bbt version counter in the oob are of the page
> - * @version: version read from the bbt page during scan
> - * @len: length of the pattern, if 0 no pattern check is performed
> - * @maxblocks: maximum number of blocks to search for a bbt. This
> number of
> - * blocks is reserved at the end of the device where the tables are
> - * written.
> - * @reserved_block_code: if non-0, this pattern denotes a reserved (rather
> than
> - * bad) block in the stored bbt
> - * @pattern: pattern to identify bad block table or factory marked good /
> - * bad blocks, can be NULL, if len = 0
> - *
> - * Descriptor for the bad block table marker and the descriptor for the
> - * pattern which identifies good and bad blocks. The assumption is made
> - * that the pattern and the version count are always located in the oob area
> - * of the first block.
> - */
> -struct nand_bbt_descr {
> - int options;
> - int pages[NAND_MAX_CHIPS];
> - int offs;
> - int veroffs;
> - uint8_t version[NAND_MAX_CHIPS];
> - int len;
> - int maxblocks;
> - int reserved_block_code;
> - uint8_t *pattern;
> -};
> -
> -/* Options for the bad block table descriptors */
> -
> -/* The number of bits used per block in the bbt on the device */
> -#define NAND_BBT_NRBITS_MSK 0x000F
> -#define NAND_BBT_1BIT0x0001
> -#define NAND_BBT_2BIT0x0002
> -#define NAND_BBT_4BIT0x0004
> -#define NAND_BBT_8BIT0x0008
> -/* The bad block table is in the last good block of the device */
> -#define NAND_BBT_LASTBLOCK 0x0010
> -/* The bbt is at the given page, else we must scan for the bbt */
> -#define NAND_BBT_ABSPAGE 0x0020
> -/* bbt is stored per chip on multichip devices */
> -#define NAND_BBT_PERCHIP 0x0080
> -/* bbt has a version counter at offset veroffs */
> -#define NAND_BBT_VERSION 0x0100
> -/* Create a bbt if none exists */
> -#define NAND_BBT_CREATE 0x0200
> -/*
> - * Create an empty BBT with no vendor information. Vendor's information
> may be
> - * unavailable, for example, if the NAND controller has a different data and
> OOB
> - * layout or if this information is already purged. Must be used in
> conjunction
> - * with NAND_BBT_CREATE.
> - */
> -#define NAND_BBT_CREATE_EMPTY0x0400
> -/* Write bbt if neccecary */
> -#define NAND_BBT_WRITE 0x2000
> -/* Read and write back block contents when writing bbt */
> -#define NAND_BBT_SAVECONTENT 0x4000
> -/* Search good / bad pattern on the first and the second page */
> -#define NAND_BBT_SCAN2NDPAGE 0x8000
> -/* Search good / bad pattern on the last page of the eraseblock */
> -#define NAND_BBT_SCANLASTPAGE0x0001
> -/*
> - * Use a flash based bad block table. By default, OOB identifier is saved in
> - * OOB area. This option is passed to the default bad block table function.
> - */
> -#define NAND_BBT_USE_FLASH 0x0002
> -/*
> - * Do not store flash based bad block table marker in the OOB area; store it
> - * in-band.
> - */
> -#define NAND_BBT_NO_OOB 0x0004
> -/*
> - * Do not write new bad block markers to OOB; useful, e.g., when ECC covers
> - * entire spare area. Must be used with NAND_BBT_USE_FLASH.
> - */
> -#define NAND_BBT_NO_OOB_BBM 0x0008
> -
> -/*
> - * Flag set by nand_create
Re: [PATCH 2/2] perf tools: Enable event_config terms to tracepoint events
On Fri, Sep 25, 2015 at 03:21:19AM +, He Kuang wrote:
SNIP
> }
>
> +__event_legacy_tracepoint:
> +PE_NAME '-' PE_NAME ':' PE_NAME
> +{
> + char sys_name[128];
> + struct str_group group;
> +
> + snprintf(&sys_name, 128, "%s-%s", $1, $3);
> + group.name1 = &sys_name;
> + group.name2 = $5;
> +
> + $$ = group;
> +}
> +|
> +PE_NAME ':' PE_NAME
> +{
> + struct str_group group = {$1, $3};
> + $$ = group;
> +}
> +
> event_legacy_numeric:
> PE_VALUE ':' PE_VALUE
> {
> --
> 1.8.5.2
>
please split this into adding the tracepoint terms parsing support
and the new tracepoint terms config logic
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] perf tools: Enable event_config terms to tracepoint events
On Fri, Sep 25, 2015 at 03:21:19AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
> index c7b904a..f13d3cc 100644
> --- a/tools/perf/util/parse-events.h
> +++ b/tools/perf/util/parse-events.h
> @@ -119,7 +119,8 @@ int parse_events__modifier_group(struct list_head *list,
> char *event_mod);
> int parse_events_name(struct list_head *list, char *name);
> int parse_events_add_tracepoint(struct list_head *list, int *idx,
> char *sys, char *event,
> - struct parse_events_error *error);
> + struct parse_events_error *error,
> + struct list_head *head_config);
> int parse_events_add_numeric(struct parse_events_evlist *data,
>struct list_head *list,
>u32 type, u64 config,
> diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> index 8bcc458..6b15a80 100644
> --- a/tools/perf/util/parse-events.y
> +++ b/tools/perf/util/parse-events.y
> @@ -67,6 +67,7 @@ static inc_group_count(struct list_head *list,
> %type event_legacy_cache
> %type event_legacy_mem
> %type event_legacy_tracepoint
> +%type __event_legacy_tracepoint
> %type event_legacy_numeric
> %type event_legacy_raw
> %type event_def
> @@ -84,6 +85,10 @@ static inc_group_count(struct list_head *list,
> u64 num;
> struct list_head *head;
> struct parse_events_term *term;
> + struct str_group{
> + char *name1;
> + char *name2;
> + } str_group;
perhaps tracepoint_name would be more suitable?
with 'struct tracepoint_name' instead of str_group
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin
Am Montag, den 21.09.2015, 15:15 +0100 schrieb Russell King - ARM Linux: > On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote: > > On Wed, Sep 16, 2015 at 01:41:38PM -0700, Douglas Anderson wrote: > > > There's a member in 'struct dw_hdmi' called cable_plugin. It's never > > > set to anything anywhere so thus is always false. There's a bit of code > > > checking it, but since it's always false this must be dead code. > > > Eliminate it. > > > > > > Note: if someone wants to figure out the intention of the original code > > > and implement whatever feature / fix was needed then we can drop this > > > patch. The 'cable_plugin' member has been unused since the code was > > > first added in (9aaf880 imx-drm: Add mx6 hdmi transmitter support). > > > > > > Signed-off-by: Douglas Anderson > > > --- > > > drivers/gpu/drm/bridge/dw_hdmi.c | 9 - > > > 1 file changed, 9 deletions(-) > > > > Except for the CHROMIUM: prefix this looks good to me: > > > > Reviewed-by: Thierry Reding This seems to be similar to Sascha's "drm: bridge/dw_hdmi: remove unused code" patch, except that the hdmi_disable_overflow_interrupts function could be removed too. > > Russell, do you have patches to this driver queued for v4.4 and plan to > > pick this up into your tree or should I take it? > > My current patch stack for imx-drm related stuff looks like this at > present: > > drm: bridge/dw_hdmi: place PHY into low power mode when disabled > drm: bridge/dw_hdmi: start of support for pixel doubled modes > drm: bridge/dw_hdmi: remove CEC engine register definitions > drm: bridge/dw_hdmi-cec: add Designware HDMI CEC driver > cec: add HDMI CEC input driver > cec: add HDMI CEC core driver > drm: bridge/dw_hdmi: replace CTS calculation for the ACR > drm: bridge/dw_hdmi: remove ratio support from ACR code > drm: bridge/dw_hdmi: adjust pixel clock values in N calculation > drm: bridge/dw_hdmi: avoid being recursive in N calculation > drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes > drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio > drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver > drm: bridge/dw_hdmi-ahb-audio: add audio driver > drm: bridge/dw_hdmi: improve HDMI enable/disable handling > drm: bridge/dw_hdmi: add connector mode forcing > drm: bridge/dw_hdmi: add support for interlaced video modes > gpu: imx: fix support for interlaced modes > gpu: imx: simplify sync polarity setting > > I haven't yet decided what, if anything, from that stack I'm going to > try to get into the next merge window. Given the lack of interest last > time I posted these patches, I'm loosing interest myself in trying to > get them merged, especially ones which are getting on for being 2 years > old. I'm still very interested to see at least the "gpu: imx: fix support for interlaced modes" and "gpu: imx: simplify sync polarity setting" merged. May I take them into the imx-drm tree separately? Or, if I can influence your decision in this matter, I'd prefer if you could once more resend last month's series with Thierry in Cc:, and he'd either queue them with my Ack for the imx-drm patches or give his Ack for you or me to queue them. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 V1 1/3] x86, mce: MCE log size not enough for high core parts
+ x...@kernel.org On Thu, Sep 24, 2015 at 02:25:41PM -0700, Raj, Ashok wrote: > Hi Boris > > I should have expanded on it.. > > On Thu, Sep 24, 2015 at 11:07:33PM +0200, Borislav Petkov wrote: > > > > How are you ever going to call into those from an offlined CPU?! > > > > And that's easy: > > > > if (!cpu_online(cpu)) > > return; > > > > The last patch of that series had 2 changes. > > 1. Allow offline cpu's to participate in the rendezvous. Since in the odd > chance the offline cpus have any errors collected we can still report them. > (we changed mce_start/mce_end to use cpu_present_mask instead of just > online map). This is not necessarily wrong - it is just unusual. > Without this change today if i were to inject an broadcast MCE > it ends up hanging, since the offline cpu is also incrementing mce_callin. > It will always end up more than cpu_online_mask by the number of cpu's > logically offlined Yeah, I'd like to have a bit somewhere which says "don't report MCEs on this core." But we talked about this already. > Consider for e.g. if 2 thread of the core are offline. And the MLC picks up What is MLC? > an error. Other cpus in the socket can't access them. Only way is to let > those > CPUs read and report their own banks as they are core scoped. In upcoming CPUs > we have some banks that can be thread scoped as well. > > Its understood OS doesn't execute any code on those CPUs. But SMI can still > run on them, and could collect errors that can be logged. Well, that is not our problem, is it? I mean, SMM wants to stay undetected. When all of a sudden offlined cores start reporting MCEs, that's going to raise some brows. Regardless, there are other reasons why offlined cores might report MCEs - the fact that logical cores share functional units and data flow goes through them might trip the reporting on those cores. Yadda yadda... > 2. If the cpu is offline, we copied them to mce_log buffer, and them copy > those out from the rendezvous master during mce_reign(). > > If we were to replace this mce_log_add() with gen_pool_add(), then i would > have to call mce_gen_pool_add() from the offline CPU. This will end up calling > RCU functions. > > We don't want to leave any errors reported by the offline CPU for purpose > of logging. It is rare, but still interested in capturing those errors if they > were to happen. > > Does this help? So first of all, we need to hold this down somewhere, maybe in Documentation/ to explain why we're running on offlined cores. This is certainly unusual code and people will ask WTF is going on there. Then, I really really don't like a static buffer which we will have to increase with each new bigger machine configuration. This is just clumsy. It'd be probably much better to make that MCE buffer per CPU. We can say, we're allowed to log 2-3, hell, 5 errors in it and when we're done with the rendezvous, an online core goes and flushes out the error records to gen_pool. This scales much better than any artificial MCE_LOG_LEN size. Oh, and we either overwrite old errors when we fill up the percpu buffer or we return. that's something we can discuss later. Or we come up with a bit smarter strategy of selecting which ones to overwrite. Just artificially increasing a static buffer is not good design IMO. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kexec: Use file name as the output message prefix
kexec output message misses the prefix "kexec", when Dave Young split
the kexec code. Now, we use file name as the output message prefix.
Currently, the format of output message:
[ 140.290795] SYSC_kexec_load: hello, world
[ 140.291534] kexec: sanity_check_segment_list: hello, world
Ideally, the format of output message:
[ 30.791503] kexec: SYSC_kexec_load, Hello, world
[ 79.182752] kexec_core: sanity_check_segment_list, Hello, world
Remove the custom prefix "kexec" in output message.
Signed-off-by: Minfei Huang
Acked-by: Dave Young
---
v3:
- Move the macro to the top of the c file
v2:
- Use KBUILD_MODNAME as prefix, instead of custom string "kexec"
---
kernel/kexec.c | 2 ++
kernel/kexec_core.c | 4 ++--
kernel/kexec_file.c | 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4c5edc3..d873b64 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -6,6 +6,8 @@
* Version 2. See the file COPYING for more details.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 201b453..dd21c78 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -6,7 +6,7 @@
* Version 2. See the file COPYING for more details.
*/
-#define pr_fmt(fmt)"kexec: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
#include
@@ -1027,7 +1027,7 @@ static int __init crash_notes_memory_init(void)
crash_notes = __alloc_percpu(size, align);
if (!crash_notes) {
- pr_warn("Kexec: Memory allocation for saving cpu register
states failed\n");
+ pr_warn("Memory allocation for saving cpu register states
failed\n");
return -ENOMEM;
}
return 0;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 6a9a3f2..b70ada0 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -9,6 +9,8 @@
* Version 2. See the file COPYING for more details.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] usb: gadget: f_midi: free request when usb_ep_queue fails
On Thu, Sep 24, 2015 at 2:20 AM, Peter Chen wrote:
> On Wed, Sep 23, 2015 at 12:40:46PM +0100, Felipe Tonello wrote:
>> Hi Peter,
>>
>> On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen wrote:
>> > On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
>> >> This fix a memory leak that will occur in this case.
>> >>
>> >> Signed-off-by: Felipe F. Tonello
>> >> ---
>> >> drivers/usb/gadget/function/f_midi.c | 4 +++-
>> >> 1 file changed, 3 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/usb/gadget/function/f_midi.c
>> >> b/drivers/usb/gadget/function/f_midi.c
>> >> index e92aff5..e6a114b 100644
>> >> --- a/drivers/usb/gadget/function/f_midi.c
>> >> +++ b/drivers/usb/gadget/function/f_midi.c
>> >> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi,
>> >> struct usb_request *req)
>> >> int err;
>> >>
>> >> err = usb_ep_queue(ep, req, GFP_ATOMIC);
>> >> - if (err < 0)
>> >> + if (err < 0) {
>> >> ERROR(midi, "%s queue req: %d\n",
>> >> midi->in_ep->name, err);
>> >> + free_ep_req(ep, req);
>> >> + }
>> >> } else {
>> >> free_ep_req(ep, req);
>> >> }
>> >> --
>> >> 2.1.4
>> >>
>> >
>> > I may know your problem, current midi library, alsa and this driver
>> > allow device sends as much data as possible, but without block the
>> > sending until host reads data, it only allocates the request buffer
>> > (using midi_alloc_ep_req), but without free, so after you send
>> > enough data, it is out of memory.
>>
>> Yes. Also there is the case where the usb cable is not conected, thus
>> failing to hardware enqueue the request, causing a memory leak on this
>> request.
>>
>
> If the usb cable is not connected, the related endpoints should be
> not enabled. Would you really observe enqueue the request without
> cable connected?
The usb_ep_queue() returns an error if it is not connected, causing
the request never to be freed and never to be queued. Thus a memory
leak happens.
Felipe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] zbud: allow up to PAGE_SIZE allocations
> Have you seen those symptoms before? How did you come up to a conclusion > that zram->zbud will do the trick? I have data from various tests (partially described here: https://lkml.org/lkml/2015/9/17/244) and once again, I'll post a reply to https://lkml.org/lkml/2015/9/15/33 with more detailed test description and explanation why zsmalloc is not the right choice for me. > If those symptoms are some sort of a recent addition, then does it help > when you disable zsmalloc compaction? No it doesn't. OTOH enabled zsmalloc compaction doesn't seem to have a substantial effect either. ~vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] soc: mediatek: Fix random hang up issue while kernel init
Am Freitag, den 25.09.2015, 14:31 +0800 schrieb James Liao:
> In kernel late init, it turns off all unused clocks, which
> needs to access subsystem registers such as VENC and VENC_LT.
>
> Accessing MT8173 VENC registers needs two top clocks, mm_sel and
> venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
> So we need to keep these clocks on before accessing their registers.
>
> This patch keeps venc_sel / venclt_sel clock on when
> VENC / VENC_LT's power is on, to prevent system hang up while
> accessing its registeres.
>
This changes the binding of an existing driver, so it needs some more
consideration. Are VENC_SEL and VENC_LT_SEL really direct clock inputs
to the VENC module, or are they some kind of parent clock for one of the
existing clocks used by the old VENC binding?
If they are direct clock inputs to the VENC module, changing the binding
might be still ok at that point, as there shouldn't be many users of
that yet. But then we at least need a corresponding change to the
binding documentation.
Regards,
Lucas
> Signed-off-by: James Liao
> ---
>
> This patch is based on v4.3-rc2, to fix system hanging up issue
> while disabling unused clocks.
>
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++-
> drivers/soc/mediatek/mtk-scpsys.c| 67
> +---
> 2 files changed, 48 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..188917f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -227,8 +227,10 @@
> #power-domain-cells = <1>;
> reg = <0 0x10006000 0 0x1000>;
> clocks = <&clk26m>,
> - <&topckgen CLK_TOP_MM_SEL>;
> - clock-names = "mfg", "mm";
> + <&topckgen CLK_TOP_MM_SEL>,
> + <&topckgen CLK_TOP_VENC_SEL>,
> + <&topckgen CLK_TOP_VENC_LT_SEL>;
> + clock-names = "mfg", "mm", "venc", "venc_lt";
> infracfg = <&infracfg>;
> };
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 164a7d8..06032ba 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -54,12 +54,16 @@
> #define PWR_STATUS_USB BIT(25)
>
> enum clk_id {
> + MT8173_CLK_NONE,
> MT8173_CLK_MM,
> MT8173_CLK_MFG,
> - MT8173_CLK_NONE,
> - MT8173_CLK_MAX = MT8173_CLK_NONE,
> + MT8173_CLK_VENC,
> + MT8173_CLK_VENC_LT,
> + MT8173_CLK_MAX,
> };
>
> +#define MAX_CLKS 2
> +
> struct scp_domain_data {
> const char *name;
> u32 sta_mask;
> @@ -67,7 +71,7 @@ struct scp_domain_data {
> u32 sram_pdn_bits;
> u32 sram_pdn_ack_bits;
> u32 bus_prot_mask;
> - enum clk_id clk_id;
> + enum clk_id clk_id[MAX_CLKS];
> };
>
> static const struct scp_domain_data scp_domain_data[] __initconst = {
> @@ -77,7 +81,7 @@ static const struct scp_domain_data scp_domain_data[]
> __initconst = {
> .ctl_offs = SPM_VDE_PWR_CON,
> .sram_pdn_bits = GENMASK(11, 8),
> .sram_pdn_ack_bits = GENMASK(12, 12),
> - .clk_id = MT8173_CLK_MM,
> + .clk_id = {MT8173_CLK_MM},
> },
> [MT8173_POWER_DOMAIN_VENC] = {
> .name = "venc",
> @@ -85,7 +89,7 @@ static const struct scp_domain_data scp_domain_data[]
> __initconst = {
> .ctl_offs = SPM_VEN_PWR_CON,
> .sram_pdn_bits = GENMASK(11, 8),
> .sram_pdn_ack_bits = GENMASK(15, 12),
> - .clk_id = MT8173_CLK_MM,
> + .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
> },
> [MT8173_POWER_DOMAIN_ISP] = {
> .name = "isp",
> @@ -93,7 +97,7 @@ static const struct scp_domain_data scp_domain_data[]
> __initconst = {
> .ctl_offs = SPM_ISP_PWR_CON,
> .sram_pdn_bits = GENMASK(11, 8),
> .sram_pdn_ack_bits = GENMASK(13, 12),
> - .clk_id = MT8173_CLK_MM,
> + .clk_id = {MT8173_CLK_MM},
> },
> [MT8173_POWER_DOMAIN_MM] = {
> .name = "mm",
> @@ -101,7 +105,7 @@ static const struct scp_domain_data scp_domain_data[]
> __initconst = {
> .ctl_offs = SPM_DIS_PWR_CON,
> .sram_pdn_bits = GENMASK(11, 8),
> .sram_pdn_ack_bits = GENMASK(12, 12),
> - .clk_id = MT8173_CLK_MM,
> + .clk_id = {MT8173_CLK_MM},
> .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
> MT8173_TOP_AXI_PROT_EN_MM_M1,
> },
> @@ -111,7 +115,7 @@ static const struct scp_domain_data scp_domain_data[]
> __initconst = {
> .ctl_offs = SPM_VEN2_PWR_CON,
>
Re: [PATCH v2 1/3] usb: chipidea: core: fix when building without CONFIG_PM support
Hi Peter, On Thu, Sep 24, 2015 at 2:17 AM, Peter Chen wrote: > On Wed, Sep 23, 2015 at 12:56:58PM +0100, Felipe F. Tonello wrote: >> If CONFIG_PM or CONFIG_PM_SLEEP is not set, driver will not compile >> properly. >> > > Would you post the warning or error messages? > > I just tried at v4.3-rc1 (v4.2 should be same), without any problems. Actually I tested again with the latest and it doesn't break. But still I believe it is the right thing to do, even though it builds. Just good practice to make sure the ifdefs are correct on driver code. Felipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3] net: Fix Hisilicon Network Subsystem Support Compilation
This patch fixes the compilation error with arm allmodconfig, this error
generated due to unavailability of readq() on 32-bit platform which was
found during net-next daily compilation. In the same time, fix all the
hns drivers compilation warnings.
Sgned-off-by: huangdaode
Signed-off-by: zhaungyuzeng
Signed-off-by: kenneth Lee
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 4 ++--
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 10 --
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 17 -
6 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a8bd27b..95bf42a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -86,7 +86,7 @@ int hns_mac_get_sfp_prsnt(struct hns_mac_cb *mac_cb, int
*sfp_prsnt)
if (!mac_cb->cpld_vaddr)
return -ENODEV;
- *sfp_prsnt = !dsaf_read_b((u64)mac_cb->cpld_vaddr
+ *sfp_prsnt = !dsaf_read_b((u8 *)mac_cb->cpld_vaddr
+ MAC_SFP_PORT_OFFSET);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index e0417c0..315b07e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -43,7 +43,7 @@ struct hns_mac_cb;
#define DSAF_DUMP_REGS_NUM 504
#define DSAF_STATIC_NUM 28
-#define DSAF_STATS_READ(p, offset) (*((u64 *)((u64)(p) + (offset
+#define DSAF_STATS_READ(p, offset) (*((u64 *)((u8 *)(p) + (offset
enum hal_dsaf_mode {
HRD_DSAF_NO_DSAF_MODE = 0x0,
@@ -302,7 +302,7 @@ struct dsaf_device {
static inline void *hns_dsaf_dev_priv(const struct dsaf_device *dsaf_dev)
{
- return (void *)((u64)dsaf_dev + sizeof(*dsaf_dev));
+ return (void *)((u8 *)dsaf_dev + sizeof(*dsaf_dev));
}
struct dsaf_drv_tbl_tcam_key {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 50f3427..1e10f65 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -191,9 +191,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb
*ring_pair, int ring_type)
if (ring_type == RX_RING) {
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_L_REG,
(u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG,
(u32)(dma >> 32));
-
+#else
+ dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
bd_size_type);
dsaf_write_dev(q, RCB_RING_RX_RING_BD_NUM_REG,
@@ -203,9 +206,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb
*ring_pair, int ring_type)
} else {
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_L_REG,
(u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG,
(u32)(dma >> 32));
-
+#else
+ dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_TX_RING_BD_LEN_REG,
bd_size_type);
dsaf_write_dev(q, RCB_RING_TX_RING_BD_NUM_REG,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 6fc58ba..b475e1b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -967,6 +967,6 @@ static inline u32 dsaf_get_reg_field(void *base, u32 reg,
u32 mask, u32 shift)
readb((__iomem unsigned char *)(addr))
#define hns_mac_reg_read64(drv, offset) \
- readq((__iomem void *)(((u64)(drv)->io_base + 0xc00 + (offset
+ readq((__iomem void *)(((u8 *)(drv)->io_base + 0xc00 + (offset
#endif /* _DSAF_REG_H */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index fe7fa1d..dab5ecf 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include "hns_dsaf_main.h"
#include "hns_dsaf_mac.h"
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 0713ced..ce7f2e0 100644
--- a/drivers/net/ethernet/hisilicon/hns
[PATCH net-next v2] net: Fix Hisilicon Network Subsystem Support Compilation
This patch fixes the compilation error with arm allmodconfig, this error
generated due to unavailability of readq() on 32-bit platform which was
found during net-next daily compilation. In the same time, fix all the
hns drivers compilation warnings.
Sgned-off-by: huangdaode
Signed-off-by: zhaungyuzeng
Signed-off-by: kenneth Lee
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 4 ++--
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 10 --
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 17 -
6 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a8bd27b..95bf42a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -86,7 +86,7 @@ int hns_mac_get_sfp_prsnt(struct hns_mac_cb *mac_cb, int
*sfp_prsnt)
if (!mac_cb->cpld_vaddr)
return -ENODEV;
- *sfp_prsnt = !dsaf_read_b((u64)mac_cb->cpld_vaddr
+ *sfp_prsnt = !dsaf_read_b((u8 *)mac_cb->cpld_vaddr
+ MAC_SFP_PORT_OFFSET);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index e0417c0..315b07e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -43,7 +43,7 @@ struct hns_mac_cb;
#define DSAF_DUMP_REGS_NUM 504
#define DSAF_STATIC_NUM 28
-#define DSAF_STATS_READ(p, offset) (*((u64 *)((u64)(p) + (offset
+#define DSAF_STATS_READ(p, offset) (*((u64 *)((u8 *)(p) + (offset
enum hal_dsaf_mode {
HRD_DSAF_NO_DSAF_MODE = 0x0,
@@ -302,7 +302,7 @@ struct dsaf_device {
static inline void *hns_dsaf_dev_priv(const struct dsaf_device *dsaf_dev)
{
- return (void *)((u64)dsaf_dev + sizeof(*dsaf_dev));
+ return (void *)((u8 *)dsaf_dev + sizeof(*dsaf_dev));
}
struct dsaf_drv_tbl_tcam_key {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 50f3427..1e10f65 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -191,9 +191,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb
*ring_pair, int ring_type)
if (ring_type == RX_RING) {
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_L_REG,
(u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG,
(u32)(dma >> 32));
-
+#else
+ dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
bd_size_type);
dsaf_write_dev(q, RCB_RING_RX_RING_BD_NUM_REG,
@@ -203,9 +206,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb
*ring_pair, int ring_type)
} else {
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_L_REG,
(u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG,
(u32)(dma >> 32));
-
+#else
+ dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_TX_RING_BD_LEN_REG,
bd_size_type);
dsaf_write_dev(q, RCB_RING_TX_RING_BD_NUM_REG,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 6fc58ba..b475e1b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -967,6 +967,6 @@ static inline u32 dsaf_get_reg_field(void *base, u32 reg,
u32 mask, u32 shift)
readb((__iomem unsigned char *)(addr))
#define hns_mac_reg_read64(drv, offset) \
- readq((__iomem void *)(((u64)(drv)->io_base + 0xc00 + (offset
+ readq((__iomem void *)(((u8 *)(drv)->io_base + 0xc00 + (offset
#endif /* _DSAF_REG_H */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index fe7fa1d..dab5ecf 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include "hns_dsaf_main.h"
#include "hns_dsaf_mac.h"
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 0713ced..ce7f2e0 100644
--- a/drivers/net/ethernet/hisilicon/hns
Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
> I already said questions, opinion and concerns but anything is not clear > until now. Only clear thing I could hear is just "compaction stats are > better" which is not enough for me. Sorry. > > 1) https://lkml.org/lkml/2015/9/15/33 > 2) https://lkml.org/lkml/2015/9/21/2 Could you please stop perverting the facts, I did answer to that: https://lkml.org/lkml/2015/9/21/753. Apart from that, an opinion is not necessarily something I would answer. Concerns about zsmalloc are not in the scope of this patch's discussion. If you have any concerns regarding this particular patch, please let us know. > Vitally, Please say what's the root cause of your problem and if it > is external fragmentation, what's the problem of my approach? > > 1) make non-LRU page migrate > 2) provide zsmalloc's migratpage The problem with your approach is that in your world I need to prove my right to use zbud. This is a very strange speculation. > We should provide it for CMA as well as external fragmentation. > I think we could solve your issue with above approach and > it fundamentally makes zsmalloc/zbud happy in future. I doubt that but I'll answer in this thread: https://lkml.org/lkml/2015/9/15/33 as zsmalloc deficiencies do not have direct relation to this particular patch. > Also, please keep it in mind that zram has been in linux kernel for > memory efficiency for a long time and later zswap/zbud was born > for *determinism* at the cost of memory efficiency. Yep, and determinism is more important to me than the memory efficiency. Dropping the compression ration from 3.2x to 1.8x is okay with me and stalls in UI are not. ~vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] perf tools: Prompt error message for wrong terms of hw/sw events
On Fri, Sep 25, 2015 at 03:21:18AM +, He Kuang wrote:
SNIP
> static int config_attr(struct perf_event_attr *attr,
> struct list_head *head,
> -struct parse_events_error *err)
> +struct parse_events_error *err,
> +config_term_func_t config_term)
> {
> struct parse_events_term *term;
>
> @@ -735,7 +751,8 @@ int parse_events_add_numeric(struct parse_events_evlist
> *data,
> attr.config = config;
>
> if (head_config) {
> - if (config_attr(&attr, head_config, data->error))
> + if (config_attr(&attr, head_config, data->error,
> + config_term_common))
> return -EINVAL;
>
> if (get_config_terms(head_config, &config_terms))
> @@ -795,7 +812,7 @@ int parse_events_add_pmu(struct parse_events_evlist *data,
>* Configure hardcoded terms first, no need to check
>* return value when called with fail == 0 ;)
>*/
> - if (config_attr(&attr, head_config, data->error))
> + if (config_attr(&attr, head_config, data->error, config_term_pmu))
> return -EINVAL;
>
> if (get_config_terms(head_config, &config_terms))
> @@ -1861,3 +1878,26 @@ void parse_events_evlist_error(struct
> parse_events_evlist *data,
> err->str = strdup(str);
> WARN_ONCE(!err->str, "WARNING: failed to allocate error string");
could you please plit this into the part that adds the
config_term callback and the error message formating change?
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] zbud: allow up to PAGE_SIZE allocations
On (09/25/15 11:13), Minchan Kim wrote: > > Ok, I can see that having the allocator backends for zpool > > have the same set of constraints is nice. > > Sorry for delay. I'm on vacation until next week. > It seems Seth was missed in previous discusstion which was not the end. > > I already said questions, opinion and concerns but anything is not clear > until now. Only clear thing I could hear is just "compaction stats are > better" which is not enough for me. Sorry. Agree. There weren't lots of answers, really. Vitaly, Have you seen those symptoms before? How did you come up to a conclusion that zram->zbud will do the trick? If those symptoms are some sort of a recent addition, then does it help when you disable zsmalloc compaction? --- diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index f59e8eb..b6c6a19 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1944,8 +1944,8 @@ struct zs_pool *zs_create_pool(const char *name, gfp_t flags) * Not critical, we still can use the pool * and user can trigger compaction manually. */ - if (zs_register_shrinker(pool) == 0) - pool->shrinker_enabled = true; +/* if (zs_register_shrinker(pool) == 0) + pool->shrinker_enabled = true;*/ return pool; err: --- p.s. I'll be on vacation next week, so most likely will be quite slow to answer. -ss > > 1) https://lkml.org/lkml/2015/9/15/33 > 2) https://lkml.org/lkml/2015/9/21/2 > > Vitally, Please say what's the root cause of your problem and if it > is external fragmentation, what's the problem of my approach? > > 1) make non-LRU page migrate > 2) provide zsmalloc's migratpage > > We should provide it for CMA as well as external fragmentation. > I think we could solve your issue with above approach and > it fundamentally makes zsmalloc/zbud happy in future. > > Also, please keep it in mind that zram has been in linux kernel for > memory efficiency for a long time and later zswap/zbud was born > for *determinism* at the cost of memory efficiency. > > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/9] mm/compaction: introduce compaction depleted state on zone
On 08/24/2015 04:19 AM, Joonsoo Kim wrote:
> Further compaction attempt is deferred when some of compaction attempts
> already fails. But, after some number of trial are skipped, compaction
> restarts work to check whether compaction is now possible or not. It
> scans whole range of zone to determine this possibility and if compaction
> possibility doesn't recover, this whole range scan is quite big overhead.
> As a first step to reduce this overhead, this patch implement compaction
> depleted state on zone.
>
> The way to determine depletion of compaction possility is checking number
> of success on previous compaction attempt. If number of successful
> compaction is below than specified threshold, we guess that compaction
> will not successful next time so mark the zone as compaction depleted.
> In this patch, threshold is choosed by 1 to imitate current compaction
> deferring algorithm. In the following patch, compaction algorithm will be
> changed and this threshold is also adjusted to that change.
>
> In this patch, only state definition is implemented. There is no action
> for this new state so no functional change. But, following patch will
> add some handling for this new state.
>
> Signed-off-by: Joonsoo Kim
> ---
> include/linux/mmzone.h | 3 +++
> mm/compaction.c| 44 +---
> 2 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 754c259..700e9b5 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -517,6 +517,8 @@ struct zone {
> unsigned intcompact_considered;
> unsigned intcompact_defer_shift;
> int compact_order_failed;
> + unsigned long compact_success;
> + unsigned long compact_depletion_depth;
> #endif
>
> #if defined CONFIG_COMPACTION || defined CONFIG_CMA
> @@ -543,6 +545,7 @@ enum zone_flags {
>* many pages under writeback
>*/
> ZONE_FAIR_DEPLETED, /* fair zone policy batch depleted */
> + ZONE_COMPACTION_DEPLETED, /* compaction possiblity depleted */
> };
>
> static inline unsigned long zone_end_pfn(const struct zone *zone)
> diff --git a/mm/compaction.c b/mm/compaction.c
> index c2d3d6a..de96e9d 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -129,6 +129,23 @@ static struct page *pageblock_pfn_to_page(unsigned long
> start_pfn,
>
> /* Do not skip compaction more than 64 times */
> #define COMPACT_MAX_DEFER_SHIFT 6
> +#define COMPACT_MIN_DEPLETE_THRESHOLD 1UL
> +
> +static bool compaction_depleted(struct zone *zone)
> +{
> + unsigned long threshold;
> + unsigned long success = zone->compact_success;
> +
> + /*
> + * Now, to imitate current compaction deferring approach,
> + * choose threshold to 1. It will be changed in the future.
> + */
> + threshold = COMPACT_MIN_DEPLETE_THRESHOLD;
> + if (success >= threshold)
> + return false;
> +
> + return true;
> +}
>
> /*
> * Compaction is deferred when compaction fails to result in a page
> @@ -223,6 +240,16 @@ static void __reset_isolation_suitable(struct zone *zone)
> zone->compact_cached_free_pfn = end_pfn;
> zone->compact_blockskip_flush = false;
>
> + if (compaction_depleted(zone)) {
> + if (test_bit(ZONE_COMPACTION_DEPLETED, &zone->flags))
> + zone->compact_depletion_depth++;
> + else {
> + set_bit(ZONE_COMPACTION_DEPLETED, &zone->flags);
> + zone->compact_depletion_depth = 0;
> + }
> + }
> + zone->compact_success = 0;
It's possible that the following comment is made moot by further patches, but:
I assume doing this in __reset_isolation_suitable() is to react on the
compaction_restarting() state. But __reset_isolation_suitable() is called also
from manually invoked compaction, and from kswapd. What if compaction has
succeeded S times, but threshold is T, S < T and T is larger than 1 (by a later
patch). Then kswapd or manual compaction will reset S to zero, without giving it
chance to reach T, even when compaction would succeed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: introduce __vmx_flush_tlb to handle specific vpid
On 24/09/2015 18:12, Bandan Das wrote: > Not sure myself what's the right thing to do but this may be undesirable > in a nested environment. Assuming the processor supports global invalidation > only, this seems like a easy way for the nested guest to invalidate *all* > mappings - even the L1 specific mappings. It's not a great thing but it's already what happens if you do a global INVEPT (it calls vmx_flush_tlb, which results in a global INVVPID if the single-context variant is not supported). Even without nested virt a single guest could slow down all other guests just by triggering frequent TLB flushes (e.g. by moving around a ROM BAR thousands of times per second). It would help to know _which_ processors actually don't support single-context INVVPIDs... Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] net: Fix Hisilicon Network Subsystem Support Compilation
On 2015/9/25 15:12, David Miller wrote:
From: huangdaode
Date: Fri, 25 Sep 2015 14:47:23 +0800
@@ -966,7 +966,15 @@ static inline u32 dsaf_get_reg_field(void *base, u32 reg,
u32 mask, u32 shift)
#define dsaf_read_b(addr)\
readb((__iomem unsigned char *)(addr))
+#ifndef readq
+static inline u64 readq(void __iomem *reg)
+{
Nope, try instead "#include
yes, it's defined in #include .
will fix in v3,
thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object
On Fri, Sep 25, 2015 at 04:56:10PM +0900, Sergey Senozhatsky wrote: > > so you want to go with _noctx() callbacks implementation? > that CRYPTO_ALG_TFM_MAY_SHARE flag looks quite simple to > me. or you guys hate it? I think we should just replace crypto_pcomp with a new interface that does what you guys want. The current crypto_compress interface is simply broken because it stores per-request state in the tfm. This runs counter to every other crypto type, e.g., hash or aead. The tfm should only hold shared data, e.g., compression algorithm parameters but not per-request state. As the original pcomp author has disappeared I think you could even drop the partial stuff and just do a straight compression interface. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/9] crypto: introduce decompression API that can be called via sharable tfm object
On (09/25/15 14:26), Joonsoo Kim wrote: [..] > > > +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name, > > > + u32 type, u32 mask); > > > + > > > > this should be EXPORT_SYMBOL_GPL(). > > > > Will do in next version. > so you want to go with _noctx() callbacks implementation? that CRYPTO_ALG_TFM_MAY_SHARE flag looks quite simple to me. or you guys hate it? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] KVM: nVMX: emulate the INVVPID instruction
On 24/09/2015 17:45, Bandan Das wrote: > > However, I have applied the patch to kvm/queue. Please send the changes > > separately, and I will squash them in the existing VPID patch. > > Please don't do this. It's making it really difficult to review these > patches individually :( Why not let them get some review time before > applying them all together ? Ok---I did it because it makes sense to keep this patch separate from the others. You can expose VPID even if vpid02 == vpid01 (in fact that's what happens if KVM cannot find a vpid02) and in that case this patch provides a valid implementation of INVVPID. Do you think it would help if I posted the whole kvm/queue contents a few days before pushing it to kvm/next? Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed
Hi, Charles, On Thu, 24 Sep 2015 08:41:07 +0100 Charles Keepax wrote: > On Thu, Sep 24, 2015 at 10:38:09AM +0900, Inha Song wrote: > > Hi, Charles, > > > > On Wed, 23 Sep 2015 15:43:12 +0100 > > Charles Keepax wrote: > > > > > On Wed, Sep 23, 2015 at 11:04:04AM +0900, Inha Song wrote: > > > > Hi, Charles, > > > > > > > > I saw the log with LOG_DEVICE in regmap. But, I'm not sure the reason > > > > that suspend noirq failed is IRQ occuring. > > > > > > > > Here is my log: > > > > -- > > > > root@localhost:~# aplay test.wav > > > > [ 41.049072] s3c64xx_spi_runtime_suspend > > > > [ 41.056043] arizona spi1.0: ASRC underclocked > > > > > > > > [ 72.308238] arizona spi1.0: Suspend, disabling IRQ > > > > [ 72.320286] arizona spi1.0: 400 <= 0 > > > > [ 72.320310] s3c64xx_spi_runtime_resume > > > > [ 72.336047] arizona spi1.0: 51a <= 0 > > > > [ 72.336217] arizona spi1.0: 101 <= 8604 > > > > [ 72.336401] arizona spi1.0: 171 <= 3 > > > > [ 72.336425] arizona spi1.0: 171 <= 2 > > > > [ 72.336731] arizona spi1.0: 171 <= 0 > > > > [ 72.336751] arizona spi1.0: SYSCLK cleared > > > > [ 72.338584] arizona spi1.0: SYSCLK cleared > > > > > > This bit looks likely related to your problem, it looks like the > > > FLL is being turned off. My guess here would be that you haven't > > > called snd_soc_dapm_ignore_suspend from your machine driver, you > > > need to call this for all end points that may want to stay > > > powered up during system suspend and also set the ignore_suspend > > > flag on any DAI links you want to remain active during system > > > suspend. > > > > But, We should call the trigger callback with SNDRV_PCM_TRIGGER_SUSPEND and > > *_RESUME command > > for support senarios what suspend during the playback and resume. > > So, I can't set the "ignore_suspend" in playback DAI. > > > > For this reason, I would have called the runtime_suspend manually in > > arizona-core when suspend. > > > > Best Reagrds, > > Inha Song. > > > > Ah ok so you want the audio to stop during suspend? Yes, I want to stop when suspend and continuous play when resume. > > Ok in that case can we get a bit more of log, your log finished > up here: > > [ 72.308238] arizona spi1.0: Suspend, disabling IRQ > [ 72.320286] arizona spi1.0: 400 <= 0 > [ 72.320310] s3c64xx_spi_runtime_resume > [ 72.336047] arizona spi1.0: 51a <= 0 > [ 72.336217] arizona spi1.0: 101 <= 8604 > [ 72.336401] arizona spi1.0: 171 <= 3 > [ 72.336425] arizona spi1.0: 171 <= 2 > [ 72.336731] arizona spi1.0: 171 <= 0 > [ 72.336751] arizona spi1.0: SYSCLK cleared > [ 72.338584] arizona spi1.0: SYSCLK cleared > [ 72.339123] s3c64xx_spi_suspend > [ 72.355866] arizona spi1.0: Late suspend, reenabling IRQ > [ 72.355893] >>> noirq failed because of spi1 > [ 72.355948] arizona spi1.0: Early resume, disabling IRQ > [ 72.416798] PM: noirq suspend of devices failed > > Which finished too early as we can't see which IRQ it was that > triggered the wakeup. But, I can't find any spi regmap log that for IRQ. -- [ 114.282681] arizona spi1.0: Late suspend, reenabling IRQ [ 114.282708] >>> noirq failed because of spi1 [ 114.282760] arizona spi1.0: Early resume, disabling IRQ [ 114.316510] PM: noirq suspend of devices failed [ 114.333590] s3c64xx_spi_resume -> set the FLL in machine for playback when resume. [ 114.334756] arizona spi1.0: FLL1: Fref=2400 Fout=135475200 [ 114.334762] arizona spi1.0: FLL1: Fvco=90316800Hz [ 114.334792] arizona spi1.0: FLL1: GCD=19200 [ 114.334798] arizona spi1.0: FLL1: N=7 THETA=149 LAMBDA=271 [ 114.334803] arizona spi1.0: FLL1: FRATIO=0(0) OUTDIV=2 REFCLK_DIV=1 [ 114.334807] arizona spi1.0: FLL1: GAIN=4 [ 114.334827] arizona spi1.0: 171 <= 1 [ 114.520724] arizona spi1.0: Late resume, reenabling IRQ [ 114.521152] arizona spi1.0: d40 => 3 [ 114.521387] arizona spi1.0: d04 <= 1 [ 114.521500] arizona spi1.0: FLL1: clock OK [ 114.521773] arizona spi1.0: SYSCLK set to 135475200Hz [ 114.522651] arizona spi1.0: SYSCLK set to 135475200Hz [ 114.522752] arizona spi1.0: 101 <= 8644 [ 114.522940] arizona spi1.0: 51a <= 1 [ 114.523057] arizona spi1.0: 400 <= 8 [ 114.909270] s3c64xx_spi_runtime_suspend [ 114.909721] done. Suspended. Trying resume. Failed. Restarting stream. Done. -> retry to enter suspend Immediately. [ 115.478349] arizona spi1.0: Suspend, disabling IRQ [ 115.489783] arizona spi1.0: 400 <= 0 [ 115.489804] s3c64xx_spi_runtime_resume [ 115.506127] arizona spi1.0: 51a <= 0 [ 115.506298] arizona spi1.0: 101 <= 8604 [ 115.506493] arizona spi1.0: 171 <= 3 [ 115.506515] arizona spi1.0: 171 <= 2 [ 115.506777] arizona spi1.0: 171 <= 0 [ 115.506793] arizona spi1.0: SYSCLK cleared [ 115.507842] arizona spi1.0: SYSCLK cleared [ 115.508373] s3c64xx_spi_suspend [ 115.523095] arizona spi1.0: Late suspend, reenabling IRQ
Re: [PATCH] m68k/sun3: Fix virtual addresses of clock and interrupt register
Hello Geert On Fri, Sep 25, 2015 at 1:21 PM, Geert Uytterhoeven wrote: > Have you tested this? > > This means enabling/disabling interrupts never worked on Sun 3, which > I find a bit difficult to believe. > There are other 0x0f?? addresses in arch/m68k/sun3/mmu_emu.c. > Nope, just trying to do it in virtual machine, I'm learning sun3 architecture now and have some cleanups patches for it. I'll send these patches and provide more feedback when I'm able to test it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API
On (09/25/15 14:46), Joonsoo Kim wrote:
[..]
> > > struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
> > > {
> > > + if (comp->tfm_noctx)
> > > + return NULL;
> >
> > Hmm,, I understand why returns NULL but it seems to be awkward to use NULL
> > to express meaningful semantic and following functions relies on.
> > If I have a time, I will think over.
>
> I also think that it's not good thing but I can't think any better
> idea. Please let me know if you have better one.
yeah, me neither.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] KVM: x86: fix bogus warning about reserved bits
On 24/09/2015 12:12, Borislav Petkov wrote:
> On Thu, Sep 24, 2015 at 11:23:08AM +0800, Xiao Guangrong wrote:
>>> +static inline bool
>>> +boot_cpu_is_amd(void)
>>> +{
>>> + WARN_ON_ONCE(!tdp_enabled);
>>> + return shadow_x_mask != 0;
>>
>> shadow_x_mask != 0 is Intel's CPU.
>>
>> Borislav, could you please check shadow_x_mask == 0 instead and test it
>> again?
>
> That did the trick:
>
> [ 62.640392] kvm: zapping shadow pages for mmio generation wraparound
> [ 63.100301] cpuid(0).ebx = 68747541
> [ 63.193426] kvm [3748]: vcpu0 unhandled rdmsr: 0xc0010112
> [ 64.538294] kvm [3748]: vcpu0 unhandled rdmsr: 0xc0011021
> [ 64.866263] kvm [3748]: vcpu1 unhandled rdmsr: 0xc0011021
> [ 64.971972] kvm [3748]: vcpu2 unhandled rdmsr: 0xc0011021
> [ 65.070376] kvm [3748]: vcpu3 unhandled rdmsr: 0xc0011021
> [ 65.170625] kvm [3748]: vcpu4 unhandled rdmsr: 0xc0011021
> [ 65.272838] kvm [3748]: vcpu5 unhandled rdmsr: 0xc0011021
> [ 65.374288] kvm [3748]: vcpu6 unhandled rdmsr: 0xc0011021
> [ 65.474825] kvm [3748]: vcpu7 unhandled rdmsr: 0xc0011021
>
> That's all I got in dmesg from booting the guest - no more mmio PF
> warnings.
Great, though this doesn't yet explain why guest_cpuid_is_amd failed.
I'll look into it next week when Amazon delivers my shiny new AMD
mini-PC :) and send the patch to Linus meanwhile.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 8/9] zram: use crypto API for compression
On (09/25/15 14:43), Joonsoo Kim wrote:
[..]
> > > /* dynamic per-device compression frontend */
> > > struct zcomp {
> > > void *stream;
> > > - struct zcomp_backend *backend;
> > > + const char *backend;
> >
> > ^^ what for?
>
> Will remove.
I think that was my mistake, I realized why do you keep it
later -- to allocate new zstreams. let's keep it.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] zbud: allow up to PAGE_SIZE allocations
On Fri, Sep 25, 2015 at 07:57:53AM +0200, Vitaly Wool wrote:
> From e219a88f4cd68842e7e04e37461aba6e06555d6a Mon Sep 17 00:00:00 2001
> From: Vitaly Vul
> Date: Tue, 22 Sep 2015 14:07:01 +0200
> Subject: [PATCH] zbud: allow up to PAGE_SIZE allocations
>
> Currently zbud is only capable of allocating not more than
> PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as
> long as only zswap is using it, but other users of zbud may
> (and likely will) want to allocate up to PAGE_SIZE. This patch
> addresses that by skipping the creation of zbud internal
> structure in the beginning of an allocated page. As a zbud page
> is no longer guaranteed to contain zbud header, the following
> changes have to be applied throughout the code:
> * page->lru to be used for zbud page lists
> * page->private to hold 'under_reclaim' flag
>
> page->private will also be used to indicate if this page contains
> a zbud header in the beginning or not ('headless' flag).
>
> This patch incorporates minor fixups after Seth's comments.
>
> Signed-off-by: Vitaly Wool
In previous thread, I saw this patch is part of "support zbud into zram"
and commented out several times but have been ignored.
So, what I can do is just
Nacked-by: Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs, seqfile: always allow oom killer
Since commit 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of
oom kill processes") seq_buf_alloc() avoids calling the oom killer for
PAGE_SIZE or smaller allocations; but larger allocations can use the oom
killer via vmalloc(). Thus reads of small files can return ENOMEM, but
larger files use the oom killer to avoid ENOMEM.
Memory overcommit requires use of the oom killer to select a victim
regardless of file size.
Enable oom killer for small seq_buf_alloc() allocations.
Signed-off-by: David Rientjes
Signed-off-by: Greg Thelen
---
fs/seq_file.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 225586e141ca..a8e288755f24 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -25,12 +25,17 @@ static void seq_set_overflow(struct seq_file *m)
static void *seq_buf_alloc(unsigned long size)
{
void *buf;
+ gfp_t gfp = GFP_KERNEL;
/*
-* __GFP_NORETRY to avoid oom-killings with high-order allocations -
-* it's better to fall back to vmalloc() than to kill things.
+* For high order allocations, use __GFP_NORETRY to avoid oom-killing -
+* it's better to fall back to vmalloc() than to kill things. For small
+* allocations, just use GFP_KERNEL which will oom kill, thus no need
+* for vmalloc fallback.
*/
- buf = kmalloc(size, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
+ if (size > PAGE_SIZE)
+ gfp |= __GFP_NORETRY | __GFP_NOWARN;
+ buf = kmalloc(size, gfp);
if (!buf && size > PAGE_SIZE)
buf = vmalloc(size);
return buf;
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] m68k: Wire up direct socket calls
Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer --- v3: - No changes, v2: - Drop RFC state, - Add Acked-by, - Add missing recvmmsg and sendmmsg. --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 17 + arch/m68k/kernel/syscalltable.S | 18 +- 3 files changed, 35 insertions(+), 2 deletions(-) diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h index 244e0dbe45dbeda3..7599cb94f9a0edea 100644 --- a/arch/m68k/include/asm/unistd.h +++ b/arch/m68k/include/asm/unistd.h @@ -4,7 +4,7 @@ #include -#define NR_syscalls356 +#define NR_syscalls373 #define __ARCH_WANT_OLD_READDIR #define __ARCH_WANT_OLD_STAT diff --git a/arch/m68k/include/uapi/asm/unistd.h b/arch/m68k/include/uapi/asm/unistd.h index 61fb6cb9d2ae3c66..b29ef18adb4aa8c5 100644 --- a/arch/m68k/include/uapi/asm/unistd.h +++ b/arch/m68k/include/uapi/asm/unistd.h @@ -361,5 +361,22 @@ #define __NR_memfd_create 353 #define __NR_bpf 354 #define __NR_execveat 355 +#define __NR_socket356 +#define __NR_socketpair357 +#define __NR_bind 358 +#define __NR_connect 359 +#define __NR_listen360 +#define __NR_accept4 361 +#define __NR_getsockopt362 +#define __NR_setsockopt363 +#define __NR_getsockname 364 +#define __NR_getpeername 365 +#define __NR_sendto366 +#define __NR_sendmsg 367 +#define __NR_recvfrom 368 +#define __NR_recvmsg 369 +#define __NR_shutdown 370 +#define __NR_recvmmsg 371 +#define __NR_sendmmsg 372 #endif /* _UAPI_ASM_M68K_UNISTD_H_ */ diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S index a0ec4303f2c8e57a..e0fe52b62a3e8bec 100644 --- a/arch/m68k/kernel/syscalltable.S +++ b/arch/m68k/kernel/syscalltable.S @@ -376,4 +376,20 @@ ENTRY(sys_call_table) .long sys_memfd_create .long sys_bpf .long sys_execveat /* 355 */ - + .long sys_socket + .long sys_socketpair + .long sys_bind + .long sys_connect + .long sys_listen/* 360 */ + .long sys_accept4 + .long sys_getsockopt + .long sys_setsockopt + .long sys_getsockname + .long sys_getpeername /* 365 */ + .long sys_sendto + .long sys_sendmsg + .long sys_recvfrom + .long sys_recvmsg + .long sys_shutdown /* 370 */ + .long sys_recvmmsg + .long sys_sendmmsg -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] m68k: Wire up userfaultfd
$ ./userfaultfd 10 99 nr_pages: 2560, nr_pages_per_cpu: 2560 bounces: 98, mode: racing, userfaults: 1121 bounces: 97, mode: rnd, userfaults: 977 bounces: 96, mode:, userfaults: 1119 bounces: 95, mode: rnd racing ver poll, userfaults: 1040 bounces: 94, mode: racing ver poll, userfaults: 1022 bounces: 93, mode: rnd ver poll, userfaults: 946 bounces: 92, mode: ver poll, userfaults: 1115 bounces: 91, mode: rnd racing poll, userfaults: 977 bounces: 90, mode: racing poll, userfaults: 899 bounces: 89, mode: rnd poll, userfaults: 881 bounces: 88, mode: poll, userfaults: 1069 bounces: 87, mode: rnd racing ver, userfaults: 1114 bounces: 86, mode: racing ver, userfaults: 1109 bounces: 85, mode: rnd ver, userfaults: 1165 bounces: 84, mode: ver, userfaults: 1107 bounces: 83, mode: rnd racing, userfaults: 1134 bounces: 82, mode: racing, userfaults: 1105 bounces: 81, mode: rnd, userfaults: 1323 bounces: 80, mode:, userfaults: 1103 bounces: 79, mode: rnd racing ver poll, userfaults: 909 bounces: 78, mode: racing ver poll, userfaults: 1095 bounces: 77, mode: rnd ver poll, userfaults: 951 bounces: 76, mode: ver poll, userfaults: 1099 bounces: 75, mode: rnd racing poll, userfaults: 1035 bounces: 74, mode: racing poll, userfaults: 1097 bounces: 73, mode: rnd poll, userfaults: 1159 bounces: 72, mode: poll, userfaults: 1042 bounces: 71, mode: rnd racing ver, userfaults: 848 bounces: 70, mode: racing ver, userfaults: 1093 bounces: 69, mode: rnd ver, userfaults: 892 bounces: 68, mode: ver, userfaults: 1091 bounces: 67, mode: rnd racing, userfaults: 1219 bounces: 66, mode: racing, userfaults: 1089 bounces: 65, mode: rnd, userfaults: 988 bounces: 64, mode:, userfaults: 1087 bounces: 63, mode: rnd racing ver poll, userfaults: 882 bounces: 62, mode: racing ver poll, userfaults: 984 bounces: 61, mode: rnd ver poll, userfaults: 701 bounces: 60, mode: ver poll, userfaults: 1071 bounces: 59, mode: rnd racing poll, userfaults: 1137 bounces: 58, mode: racing poll, userfaults: 1032 bounces: 57, mode: rnd poll, userfaults: 911 bounces: 56, mode: poll, userfaults: 1079 bounces: 55, mode: rnd racing ver, userfaults: 1106 bounces: 54, mode: racing ver, userfaults: 1077 bounces: 53, mode: rnd ver, userfaults: 886 bounces: 52, mode: ver, userfaults: 1075 bounces: 51, mode: rnd racing, userfaults: 1101 bounces: 50, mode: racing, userfaults: 1073 bounces: 49, mode: rnd, userfaults: 1070 bounces: 48, mode:, userfaults: 1071 bounces: 47, mode: rnd racing ver poll, userfaults: 1077 bounces: 46, mode: racing ver poll, userfaults: 910 bounces: 45, mode: rnd ver poll, userfaults: 1063 bounces: 44, mode: ver poll, userfaults: 1028 bounces: 43, mode: rnd racing poll, userfaults: 1043 bounces: 42, mode: racing poll, userfaults: 1065 bounces: 41, mode: rnd poll, userfaults: 912 bounces: 40, mode: poll, userfaults: 1063 bounces: 39, mode: rnd racing ver, userfaults: 880 bounces: 38, mode: racing ver, userfaults: 1061 bounces: 37, mode: rnd ver, userfaults: 1144 bounces: 36, mode: ver, userfaults: 1059 bounces: 35, mode: rnd racing, userfaults: 967 bounces: 34, mode: racing, userfaults: 1057 bounces: 33, mode: rnd, userfaults: 1076 bounces: 32, mode:, userfaults: 1055 bounces: 31, mode: rnd racing ver poll, userfaults: 997 bounces: 30, mode: racing ver poll, userfaults: 1053 bounces: 29, mode: rnd ver poll, userfaults: 968 bounces: 28, mode: ver poll, userfaults: 978 bounces: 27, mode: rnd racing poll, userfaults: 1008 bounces: 26, mode: racing poll, userfaults: 1049 bounces: 25, mode: rnd poll, userfaults: 900 bounces: 24, mode: poll, userfaults: 1047 bounces: 23, mode: rnd racing ver, userfaults: 988 bounces: 22, mode: racing ver, userfaults: 1045 bounces: 21, mode: rnd ver, userfaults: 1027 bounces: 20, mode: ver, userfaults: 1043 bounces: 19, mode: rnd racing, userfaults: 1017 bounces: 18, mode: racing, userfaults: 1041 bounces: 17, mode: rnd, userfaults: 979 bounces: 16, mode:, userfaults: 1039 bounces: 15, mode: rnd racing ver poll, userfaults: 1134 bounces: 14, mode: racing ver poll, userfaults: 1037 bounces: 13, mode: rnd ver poll, userfaults: 1046 bounces: 12, mode: ver poll, userfaults: 1035 bounces: 11, mode: rnd racing poll, userfaults: 1060 bounces: 10, mode: racing poll, userfaults: 1033 bounces: 9, mode: rnd poll, userfaults: 1003 bounces: 8, mode: poll, userfaults: 929 bounces: 7, mode: rnd racing ver, userfaults: 964 bounces: 6, mode: racing ver, userfaults: 1029 bounces: 5, mode: rnd ver, userfaults: 1053 bounces: 4, mode: ver, userfaults: 1027 bounces: 3, mode: rnd racing, userfaults: 863 bounces: 2, mode: racing, userfaults: 1025 bounces: 1, mode: rnd, userfaults: 1043 bounces: 0, mode:, userfaults: 950 Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer --- v3: - No changes, v2: - Add Acked-by, - Rebased and renumbered. --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 1 + arch/m68k/kernel/syscalltable.S | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/m68k/i
[PATCH v3 3/3] m68k: Wire up membarrier
$ ./membarrier_test membarrier MEMBARRIER_CMD_QUERY syscall available. membarrier: MEMBARRIER_CMD_SHARED success. membarrier: tests done! $ Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer --- v3: - Add Acked-by, - Move before "m68k: Wire up direct ipc calls", v2: - New. --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 1 + arch/m68k/kernel/syscalltable.S | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h index d25d5a5c83cb6d6b..0793a7f174176e6d 100644 --- a/arch/m68k/include/asm/unistd.h +++ b/arch/m68k/include/asm/unistd.h @@ -4,7 +4,7 @@ #include -#define NR_syscalls374 +#define NR_syscalls375 #define __ARCH_WANT_OLD_READDIR #define __ARCH_WANT_OLD_STAT diff --git a/arch/m68k/include/uapi/asm/unistd.h b/arch/m68k/include/uapi/asm/unistd.h index 0eebb28488eced36..5e6fae6c275f9b11 100644 --- a/arch/m68k/include/uapi/asm/unistd.h +++ b/arch/m68k/include/uapi/asm/unistd.h @@ -379,5 +379,6 @@ #define __NR_recvmmsg 371 #define __NR_sendmmsg 372 #define __NR_userfaultfd 373 +#define __NR_membarrier374 #endif /* _UAPI_ASM_M68K_UNISTD_H_ */ diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S index 7b5a315f6df2c770..5dd0e80042f51107 100644 --- a/arch/m68k/kernel/syscalltable.S +++ b/arch/m68k/kernel/syscalltable.S @@ -394,3 +394,4 @@ ENTRY(sys_call_table) .long sys_recvmmsg .long sys_sendmmsg .long sys_userfaultfd + .long sys_membarrier -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] m68k: System call updates
This patch series, intended for v4.3, updates the m68k system calls: - Wire up direct socket calls, - Wire up new userfaultfd and membarrier system calls. Changes compared to v2: - Postponed adding direct ipc calls, until ipc_parse_version() is resolved, - Renumbered membarrier, Changes compared to v1: - Add missing recvmmsg and sendmmsg, - Renumbered userfaultfd, - New patches 3 and 4. Geert Uytterhoeven (3): m68k: Wire up direct socket calls m68k: Wire up userfaultfd m68k: Wire up membarrier arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 19 +++ arch/m68k/kernel/syscalltable.S | 20 +++- 3 files changed, 39 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20150812, in drivers/i2c/busses/i2c-i801.c
On Wed, 12 Aug 2015 08:42:18 -0700, Jim Davis wrote: > Building with the attached random configuration file, > > drivers/built-in.o: In function `dmi_check_onboard_devices': > i2c-i801.c:(.text+0x126b36): undefined reference to `i2c_new_device' > drivers/built-in.o: In function `i801_remove': > i2c-i801.c:(.text+0x126b86): undefined reference to `i2c_del_adapter' > drivers/built-in.o: In function `i801_probe': > i2c-i801.c:(.text+0x127d08): undefined reference to `i2c_add_adapter' > i2c-i801.c:(.text+0x127d6e): undefined reference to `i2c_new_device' Sorry for the late reply. The error is caused by the following combination of options: CONFIG_I2C=m CONFIG_I2C_I801=y I can reproduce it even with mainline now. This is caused by CONFIG_ITCO_WDT=y, which selects CONFIG_I2C_I801=y without selecting its dependencies (CONFIG_I2C.) Thanks for reporting, I'll post a fix shortly. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Please pull powerpc/linux.git powerpc-4.3-3 tag
Hi Linus, Please pull two powerpc fixes for 4.3: The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde: Linux 4.3-rc2 (2015-09-20 14:32:34 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.3-3 for you to fetch changes up to d6eb71a6d2eda21c8cd7a4dcd6207a0d94eb6ae7: cxl: Fix lockdep warning while creating afu_err_buff attribute (2015-09-23 20:57:13 +1000) powerpc fixes for 4.3 #2 - Wire up sys_membarrier() - cxl: Fix lockdep warning while creating afu_err_buff from Vaibhav Michael Ellerman (1): powerpc: Wire up sys_membarrier() Vaibhav Jain (1): cxl: Fix lockdep warning while creating afu_err_buff attribute arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + drivers/misc/cxl/sysfs.c | 2 ++ 4 files changed, 5 insertions(+), 1 deletion(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH] mm doc: Fix misleading code reference of overcommit_memory
On Fri 25-09-15 12:19:38, Chun Chen wrote: > The origin document references to cap_vm_enough_memory is because > cap_vm_enough_memory invoked __vm_enough_memory before and it no > longer does now. > > Signed-off-by: Chun Chen Acked-by: Michal Hocko > --- > Documentation/sysctl/vm.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt > index a4482fc..f72370b 100644 > --- a/Documentation/sysctl/vm.txt > +++ b/Documentation/sysctl/vm.txt > @@ -639,7 +639,7 @@ and don't use much of it. > The default value is 0. > > See Documentation/vm/overcommit-accounting and > -security/commoncap.c::cap_vm_enough_memory() for more information. > +mm/mmap.c::__vm_enough_memory() for more information. > > == > > -- > 2.1.0 > -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rwx mapping between ex_table and rodata
* Kees Cook wrote: > On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley wrote: > > Hi, > > > > With the attached config and 4.3-rc2 on x86_64, I see the following in > > /sys/kernel/debug/kernel_page_tables: > > ... > > ---[ High Kernel Mapping ]--- > > 0x8000-0x8100 16M > > pmd > > 0x8100-0x8160 6M ro PSE > > GLB x pmd > > 0x8160-0x817750001492K ro > > GLB x pte > > 0x81775000-0x8180 556K RW > > GLB x pte > > ^ Btw., I think we should run this lookup automatically in late bootup, if CONFIG_X86_PTDUMP=y, and print a WARN()ing if there's any RWX permissions in the mappings. That makes sure automated testing picks new bugs up. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rwx mapping between ex_table and rodata
* Kees Cook wrote: > On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley wrote: > > Hi, > > > > With the attached config and 4.3-rc2 on x86_64, I see the following in > > /sys/kernel/debug/kernel_page_tables: > > ... > > ---[ High Kernel Mapping ]--- > > 0x8000-0x8100 16M > > pmd > > 0x8100-0x8160 6M ro PSE > > GLB x pmd > > 0x8160-0x817750001492K ro > > GLB x pte > > 0x81775000-0x8180 556K RW > > GLB x pte > > ^ > > 0x8180-0x81a0 2M ro PSE > > GLB NX pmd > > 0x81a0-0x81b430001292K ro > > GLB NX pte > > 0x81b43000-0x82004852K RW > > GLB NX pte > > 0x8200-0x8220 2M RW PSE > > GLB NX pmd > > 0x8220-0xa000 478M > > pmd > > ... > > > > This region seems to be between the end of ex_table and the start of rodata, > > $ objdump -x vmlinux | sort > > ... > > 817728b0 g __ex_table __start___ex_table > > 817728b0 ld __ex_table __ex_table > > 81774998 g __ex_table __stop___ex_table > > 8180 g .rodata __start_rodata > > 8180 ld .rodata .rodata > > ... > > > > $ readelf -a vmlinux > > ... > > Section Headers: > > [Nr] Name Type Address Offset > >Size EntSize Flags Link Info Align > > ... > > [ 3] __ex_tablePROGBITS 817728b0 009728b0 > >20e8 A 0 0 8 > > [ 4] .rodata PROGBITS 8180 00a0 > >002eefd2 A 0 0 64 > > ... > > > > I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so > > it isn't new to 4.3. > > To me it looks like another alignment/padding issue like got fixed > before. The space between __ex_table and rodata is (seems?) unused, so > the default page table permissions end up being W+X. Can we fix the > default to be NX instead? It'll make these bugs stay gone. Yeah. Wanna send a patch for that? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k/sun3: Fix virtual addresses of clock and interrupt register
Hi Alexander,
On Mon, Sep 14, 2015 at 11:40 AM, Alexander Kuleshov
wrote:
> The MMU base is 32 bits size - 0xfe00, seems that we missed
> one zero in the definition of the clock and interrupt register
> addresses.
Thanks for your patch!
Have you tested this?
This means enabling/disabling interrupts never worked on Sun 3, which
I find a bit difficult to believe.
There are other 0x0f?? addresses in arch/m68k/sun3/mmu_emu.c.
> Signed-off-by: Alexander Kuleshov
> ---
> arch/m68k/sun3/config.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
> index a8b942b..c9c388f 100644
> --- a/arch/m68k/sun3/config.c
> +++ b/arch/m68k/sun3/config.c
> @@ -61,8 +61,8 @@ void __init sun3_init(void)
> m68k_cputype = CPU_68020;
> m68k_fputype = FPU_68881; /* mc68881 actually */
> m68k_mmutype = MMU_SUN3;
> - clock_va= (char *) 0xfe06000; /* dark */
> - sun3_intreg = (unsigned char *) 0xfe0a000; /* magic */
> + clock_va= (char *) 0xfe006000; /* dark */
> + sun3_intreg = (unsigned char *) 0xfe00a000; /* magic */
> sun3_disable_interrupts();
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] dmaengine: xgene-dma: Fix overwritting DMA tx ring
Hi Vinod,
On Wed, Sep 16, 2015 at 1:33 PM, Rameshwar Prasad Sahu wrote:
> This patch fixes an over flow issue with the TX ring descriptor. Each
> descriptor is 32B in size and an operation requires 2 of these
> descriptors.
>
> Signed-off-by: Rameshwar Prasad Sahu
> ---
> drivers/dma/xgene-dma.c | 37 +++--
> 1 file changed, 11 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index b23e8d5..21ba2cc 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -59,7 +59,6 @@
> #define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
> #define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
> #define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
> -#define XGENE_DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
> #define XGENE_DMA_RING_ID_GET(owner, num) (((owner) << 6) | (num))
> #define XGENE_DMA_RING_DST_ID(v) ((1 << 10) | (v))
> #define XGENE_DMA_RING_CMD_OFFSET 0x2C
> @@ -379,14 +378,6 @@ static u8 xgene_dma_encode_xor_flyby(u32 src_cnt)
> return flyby_type[src_cnt];
> }
>
> -static u32 xgene_dma_ring_desc_cnt(struct xgene_dma_ring *ring)
> -{
> - u32 __iomem *cmd_base = ring->cmd_base;
> - u32 ring_state = ioread32(&cmd_base[1]);
> -
> - return XGENE_DMA_RING_DESC_CNT(ring_state);
> -}
> -
> static void xgene_dma_set_src_buffer(__le64 *ext8, size_t *len,
> dma_addr_t *paddr)
> {
> @@ -659,15 +650,12 @@ static void xgene_dma_clean_running_descriptor(struct
> xgene_dma_chan *chan,
> dma_pool_free(chan->desc_pool, desc, desc->tx.phys);
> }
>
> -static int xgene_chan_xfer_request(struct xgene_dma_ring *ring,
> - struct xgene_dma_desc_sw *desc_sw)
> +static void xgene_chan_xfer_request(struct xgene_dma_chan *chan,
> + struct xgene_dma_desc_sw *desc_sw)
> {
> + struct xgene_dma_ring *ring = &chan->tx_ring;
> struct xgene_dma_desc_hw *desc_hw;
>
> - /* Check if can push more descriptor to hw for execution */
> - if (xgene_dma_ring_desc_cnt(ring) > (ring->slots - 2))
> - return -EBUSY;
> -
> /* Get hw descriptor from DMA tx ring */
> desc_hw = &ring->desc_hw[ring->head];
>
> @@ -694,11 +682,13 @@ static int xgene_chan_xfer_request(struct
> xgene_dma_ring *ring,
> memcpy(desc_hw, &desc_sw->desc2, sizeof(*desc_hw));
> }
>
> + /* Increment the pending transaction count */
> + chan->pending += ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
> +
> /* Notify the hw that we have descriptor ready for execution */
> iowrite32((desc_sw->flags & XGENE_DMA_FLAG_64B_DESC) ?
> 2 : 1, ring->cmd);
> -
> - return 0;
> }
>
> /**
> @@ -710,7 +700,6 @@ static int xgene_chan_xfer_request(struct xgene_dma_ring
> *ring,
> static void xgene_chan_xfer_ld_pending(struct xgene_dma_chan *chan)
> {
> struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
> - int ret;
>
> /*
> * If the list of pending descriptors is empty, then we
> @@ -735,18 +724,13 @@ static void xgene_chan_xfer_ld_pending(struct
> xgene_dma_chan *chan)
> if (chan->pending >= chan->max_outstanding)
> return;
>
> - ret = xgene_chan_xfer_request(&chan->tx_ring, desc_sw);
> - if (ret)
> - return;
> + xgene_chan_xfer_request(chan, desc_sw);
>
> /*
> * Delete this element from ld pending queue and append it to
> * ld running queue
> */
> list_move_tail(&desc_sw->node, &chan->ld_running);
> -
> - /* Increment the pending transaction count */
> - chan->pending++;
> }
> }
>
> @@ -821,7 +805,8 @@ static void xgene_dma_cleanup_descriptors(struct
> xgene_dma_chan *chan)
> * Decrement the pending transaction count
> * as we have processed one
> */
> - chan->pending--;
> + chan->pending -= ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
>
> /*
> * Delete this node from ld running queue and append it to
> @@ -1482,7 +1467,7 @@ static int xgene_dma_create_chan_rings(struct
> xgene_dma_chan *chan)
> tx_ring->id, tx_ring->num, tx_ring->desc_vaddr);
>
> /* Set the max outstanding request possible to this channel */
> - chan->max_outstanding = rx_ring->slots;
> + chan->max_outstanding = tx_ring->slots;
>
> return ret;
> }
> --
> 1.8.2.1
>
Any comments on above patch ??
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
Re: [PATCH 26/26] x86, pkeys: Documentation
* Andy Lutomirski wrote: > This may mean that we want to have a way for binaries to indicate that they > want > their --x segments to be loaded with a particular protection key. The right > way > to do that might be using an ELF note, and I also want to use ELF notes to > allow > turning off vsyscalls, so maybe it's time to write an ELF note parser in the > kernel. That would be absolutely lovely for many other reasons as well, and we should also add a tool to tools/ to edit/expand/shrink those ELF notes on existing systems. I.e. make it really easy to augment security policies on an existing distro, using any filesystem (not just ACL capable ones) and using the binary only. Linux binaries could carry capabilities information, etc. etc. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] drm/imx: Build monolithic driver
Hi Thierry, Am Donnerstag, den 24.09.2015, 19:02 +0200 schrieb Thierry Reding: > From: Thierry Reding > > There's no use building the individual drivers as separate modules > because they are all only useful if combined into a single DRM/KMS > device. Why not? On an i.MX5 device with VGA(tve) output only, it is nice not to have to load the i.MX6 HDMI driver. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] net: Fix Hisilicon Network Subsystem Support Compilation
From: huangdaode
Date: Fri, 25 Sep 2015 14:47:23 +0800
> @@ -966,7 +966,15 @@ static inline u32 dsaf_get_reg_field(void *base, u32
> reg, u32 mask, u32 shift)
> #define dsaf_read_b(addr)\
> readb((__iomem unsigned char *)(addr))
>
> +#ifndef readq
> +static inline u64 readq(void __iomem *reg)
> +{
Nope, try instead "#include http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key faults
* Dave Hansen wrote:
> On 09/24/2015 02:30 AM, Ingo Molnar wrote:
> >> To answer your question in the comment: it looks useful to have some sort
> >> of
> >> 'extended page fault error code' information here, which shows why the
> >> page fault
> >> happened. With the regular error_code it's easy - with protection keys
> >> there's 16
> >> separate keys possible and user-space might not know the actual key value
> >> in the
> >> pte.
> >
> > Btw., alternatively we could also say that user-space should know what
> > protection
> > key it used when it created the mapping - there's no need to recover it for
> > every
> > page fault.
>
> That's true. We don't, for instance, tell userspace whether it was a
> write that caused a fault.
I think we do put it into the signal frame, see setup_sigcontext():
put_user_ex(current->thread.error_code, &sc->err);
and 'error_code & PF_WRITE' tells us whether it's a write fault.
And I'm pretty sure applications like Valgrind rely on this.
> But, other than smaps we don't have *any* way to tell userspace what
> protection
> key a page has. I think some mechanism is going to be required for this to
> be
> reasonably debuggable.
I think it's a conceptual extension of sigcontext::err and we need it for
similar
reasons.
> > OTOH, as long as we don't do a separate find_vma(), it looks cheap enough
> > to
> > look up the pkey value of that address and give it to user-space in the
> > signal
> > frame.
>
> I still think that find_vma() in this case is pretty darn cheap, definitely
> if
> you compare it to the cost of the entire fault path.
So where's the problem? We have already looked up the vma and know whether
there's
any vma there or not. Why not pass in that pointer and be done with it? Why
complicate the code by looking up a second time (and exposing us to various
races)?
> > Btw., how does pkey support interact with hugepages?
>
> Surprisingly little. I've made sure that everything works with huge pages
> and
> that the (huge) PTEs and VMAs get set up correctly, but I'm not sure I had to
> touch the huge page code at all. I have test code to ensure that it works
> the
> same as with small pages, but everything worked pretty naturally.
Yeah, so the reason I'm asking about expectations is that this code:
+ follow_ret = follow_pte(tsk->mm, address, &ptep, &ptl);
+ if (!follow_ret) {
+ /*
+* On a successful follow, make sure to
+* drop the lock.
+*/
+ pte = *ptep;
+ pte_unmap_unlock(ptep, ptl);
+ ret = pte_pkey(pte);
is visibly hugepage-unsafe: if a vma is hugepage mapped, there are no ptes,
only
pmds - and the protection key index lives in the pmd. We don't seem to recover
that information properly.
In any case, please put those hugepage tests into tools/tests/selftests/x86/ as
well, as part of the pkey series.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Remove hardwired ABE clock configuration
On 09/25/2015 09:59 AM, Peter Ujfalusi wrote: Tero, On 09/16/2015 09:42 AM, Tero Kristo wrote: On 09/14/2015 11:52 AM, Peter Ujfalusi wrote: Hi Tero, On 08/24/2015 10:35 AM, Peter Ujfalusi wrote: The ABE related clocks should be configured via DT and not have it wired inside of the kernel. can you take a look at this patch? It will not cause any regression since we do not have audio support mainline and the pending series does not need this part anymore. This patch looks okay to me. So, you are saying this doesn't depend on anything? Isn't this causing any boot-time issues with the ABE DPLL left dangling with boot setup, potentially blocking PM? I am just wondering if we should group this patch with the rest of the audio support patches for dra7. Without this patch the ABE DPLL will have frequency which is not going to be correct to be used with the ATL. The ATL is disabled by default and only enabled when we use the audio. Which is not the case w/o the other series. Ok, queuing for 4.3-rc fixes. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 Sep 24 (netup_unidvb & if)
Hi Randy, I have checked your config. There is: # CONFIG_DVB_HORUS3A is not set in this case in drivers/media/dvb-frontends/horus3a.h incorrect statement used. I will send patch to fix this problem bit later. thanks for report ! 2015-09-25 1:36 GMT+03:00 Randy Dunlap : > On 09/24/15 14:05, Steven Rostedt wrote: >> On Thu, 24 Sep 2015 10:53:16 -0700 >> Randy Dunlap wrote: >> >>> On 09/23/15 21:53, Stephen Rothwell wrote: Hi all, Changes since 20150923: >>> >>> on x86_64: >>> >>> >> >> Compiles fine for me, and I enabled: >> >> CONFIG_PROFILE_ALL_BRANCHES=y >> CONFIG_MEDIA_SUPPORT=y >> CONFIG_MEDIA_ANALOG_TV_SUPPORT=y >> >> which looks like it should give the problem you have. >> >> What config did you use, and maybe it's a gcc version problem? > > Sorry, I should have included the randconfig file. Here it is (attached). > > > -- > ~Randy -- Abylay Ospan, NetUP Inc. http://www.netup.tv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3
Paul,
On 09/15/2015 05:10 PM, Peter Ujfalusi wrote:
> McASP3 is used by default on DRA7x based boards for audio.
Can you take a look at this patch? It would be great to have this one reviewed
so the audio support for the dra7 family could be applied by Tony.
Thanks,
Péter
> Signed-off-by: Peter Ujfalusi
> ---
> Hi Paul,
>
> this patch is part of my earlier series and as Tony suggested I'll resend the
> hwmod patch for you to review since I missed you from the TO in the series.
>
> The original series:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg119319.html
>
> Regards,
> Peter
>
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41
> +++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247bced49..c38b7fa30c27 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
> };
>
> /*
> + * 'mcasp' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
> + .sysc_offs = 0x0004,
> + .sysc_flags = SYSC_HAS_SIDLEMODE,
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields= &omap_hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
> + .name = "mcasp",
> + .sysc = &dra7xx_mcasp_sysc,
> +};
> +
> +/* mcasp3 */
> +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
> + .name = "mcasp3",
> + .class = &dra7xx_mcasp_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "mcasp3_ahclkx_mux",
> + .flags = HWMOD_SWSUP_SIDLE,
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
> + .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/*
> * 'mmc' class
> *
> */
> @@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi
> = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* l4_per2 -> mcasp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
> + .master = &dra7xx_l4_per2_hwmod,
> + .slave = &dra7xx_mcasp3_hwmod,
> + .clk= "l3_iclk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
> {
> .pa_start = 0x48078000,
> @@ -3338,6 +3378,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_wkup__dcan1,
> &dra7xx_l4_per2__dcan2,
> &dra7xx_l4_per2__cpgmac0,
> + &dra7xx_l4_per2__mcasp3,
> &dra7xx_gmac__mdio,
> &dra7xx_l4_cfg__dma_system,
> &dra7xx_l3_main_1__dss,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] dmaengine: omap-dma: Enable packed accesses for cyclic transfers
Vinod,
On 09/14/2015 03:31 PM, Peter Ujfalusi wrote:
> From: Misael Lopez Cruz
>
> The L3 throughput can be higher than expected when packed access
> is not enabled. The ratio depends on the number of bytes in a
> transaction and the EMIF interface width.
Can you take a look at this patch?
Thanks,
Péter
> The throughput was measured for the following settings/cases:
>
> * Case 1: Burst size of 64 bytes, packed access disabled
> * Case 2: Burst size of 64 bytes, packed access enabled
> * Case 3: Burst disabled, packed access disabled
>
> Throughput measurements were done during McASP-based audio
> playback on the Jacinto6 EVM using the omapconf tool [1]:
> $ omapconf trace bw -m sdma_rd
>
> -
> Throughput (MB/s)
> Audio parametersCase 1Case 2Case 3
> -
> 44.1kHz, 16-bits, stereo 1.41 0.18 1.41
> 44.1kHz, 32-bits, stereo 1.41 0.35 1.41
> 44.1kHz, 16-bits, 4-chan 2.82 0.35 2.82
> 44.1kHz, 16-bits, 6-chan 4.23 0.53 4.23
> 44.1kHz, 16-bits, 8-chan 5.64 0.71 5.64
> -
>
> From above measurements, case 2 is the only one that delivers
> the expected throughput for the given audio parameters. For
> that reason, the packed accesses are now enabled.
>
> It's worth to mention that packed accesses cannot be enabled
> for all addressing modes. In cyclic transfers, it can be
> enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
> as they use post-increment mode which supports packed accesses.
>
> Peter Ujfalusi:
> From the TRM regarding to this:
> "NOTE: Except in the constant addressing mode, the source or
> destination must be specified as packed for burst transactions
> to occur."
>
> So w/o the packed setting the burst on the MEM side was not
> enabled, this explains the numbers.
>
> [1] https://github.com/omapconf/omapconf
>
> Signed-off-by: Misael Lopez Cruz
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/omap-dma.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 249445c8a4c6..1dfc71c90123 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -935,8 +935,12 @@ static struct dma_async_tx_descriptor
> *omap_dma_prep_dma_cyclic(
> else
> d->ccr |= CCR_SYNC_ELEMENT;
>
> - if (dir == DMA_DEV_TO_MEM)
> + if (dir == DMA_DEV_TO_MEM) {
> d->ccr |= CCR_TRIGGER_SRC;
> + d->csdp |= CSDP_DST_PACKED;
> + } else {
> + d->csdp |= CSDP_SRC_PACKED;
> + }
>
> d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: ti: clk-7xx: Remove hardwired ABE clock configuration
Tero,
On 09/16/2015 09:42 AM, Tero Kristo wrote:
> On 09/14/2015 11:52 AM, Peter Ujfalusi wrote:
>> Hi Tero,
>>
>> On 08/24/2015 10:35 AM, Peter Ujfalusi wrote:
>>> The ABE related clocks should be configured via DT and not have it wired
>>> inside of the kernel.
>>
>> can you take a look at this patch? It will not cause any regression since we
>> do not have audio support mainline and the pending series does not need this
>> part anymore.
>
> This patch looks okay to me. So, you are saying this doesn't depend on
> anything? Isn't this causing any boot-time issues with the ABE DPLL left
> dangling with boot setup, potentially blocking PM? I am just wondering if we
> should group this patch with the rest of the audio support patches for dra7.
Without this patch the ABE DPLL will have frequency which is not going to be
correct to be used with the ATL. The ATL is disabled by default and only
enabled when we use the audio. Which is not the case w/o the other series.
--
Péter
>
> -Tero
>
>>
>>> Signed-off-by: Peter Ujfalusi
>>> ---
>>> Hi Tero,
>>>
>>> the ABE PLL configuration can, and will be done for dra7xx in DT with the
>>> assigned-clocks/rate/parent feature so no need to have this anymore.
>>>
>>> Regards,
>>> Peter
>>>
>>> drivers/clk/ti/clk-7xx.c | 18 +-
>>> 1 file changed, 1 insertion(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
>>> index 9b5b289e6334..a911d7de3377 100644
>>> --- a/drivers/clk/ti/clk-7xx.c
>>> +++ b/drivers/clk/ti/clk-7xx.c
>>> @@ -18,7 +18,6 @@
>>>
>>> #include "clock.h"
>>>
>>> -#define DRA7_DPLL_ABE_DEFFREQ180633600
>>> #define DRA7_DPLL_GMAC_DEFFREQ10
>>> #define DRA7_DPLL_USB_DEFFREQ96000
>>>
>>> @@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
>>> int __init dra7xx_dt_clk_init(void)
>>> {
>>> int rc;
>>> -struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
>>> +struct clk *dpll_ck, *hdcp_ck;
>>>
>>> ti_dt_clocks_register(dra7xx_clks);
>>>
>>> omap2_clk_disable_autoidle_all();
>>>
>>> -abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
>>> -sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
>>> -dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
>>> -
>>> -rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
>>> -if (!rc)
>>> -rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
>>> -if (rc)
>>> -pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>>> -
>>> -dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
>>> -rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
>>> -if (rc)
>>> -pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
>>> -
>>> dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
>>> rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
>>> if (rc)
>>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
