[PATCH] irqchip/gic-v3: Fix GIC_LINE_NR accessor
As per GIC spec, ITLinesNumber indicates the maximum SPI INTID that the GIC implementation supports. And the maximum SPI INTID an implementation might support is 1019 (field value 1). max(GICD_TYPER_SPIS(...), 1020) is not what we actually want for GIC_LINE_NR. Fix it to min(GICD_TYPER_SPIS(...), 1020). Signed-off-by: Zenghui Yu --- Hi Marc, I still see "GICv3: 992 SPIs implemented" on the host. I go back to https://patchwork.kernel.org/patch/11078623/ and it seems that we failed to make the GIC_LINE_NR correct at that time. drivers/irqchip/irq-gic-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 7b0c96b9e02f..f4a49aef5ca4 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -59,7 +59,7 @@ static struct gic_chip_data gic_data __read_mostly; static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key); #define GIC_ID_NR (1U << GICD_TYPER_ID_BITS(gic_data.rdists.gicd_typer)) -#define GIC_LINE_NRmax(GICD_TYPER_SPIS(gic_data.rdists.gicd_typer), 1020U) +#define GIC_LINE_NRmin(GICD_TYPER_SPIS(gic_data.rdists.gicd_typer), 1020U) #define GIC_ESPI_NRGICD_TYPER_ESPIS(gic_data.rdists.gicd_typer) /* -- 2.19.1
Re: [RESEND, PATCH v7 04/11] pwm: mediatek: allocate the clks array dynamically
Hi Sam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190917]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sam-Shih/Add-mt7629-and-fix-mt7628-pwm/20190918-140213
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers//pwm/pwm-mediatek.c: In function 'mtk_pwm_config':
drivers//pwm/pwm-mediatek.c:123:22: error: 'struct mtk_pwm_chip' has no
member named 'clks'
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
^~
drivers//pwm/pwm-mediatek.c:123:29: error: 'MTK_CLK_PWM1' undeclared (first
use in this function)
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
^~~~
drivers//pwm/pwm-mediatek.c:123:29: note: each undeclared identifier is
reported only once for each function it appears in
drivers//pwm/pwm-mediatek.c: In function 'mtk_pwm_probe':
>> drivers//pwm/pwm-mediatek.c:237:2: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
int i;
^~~
vim +237 drivers//pwm/pwm-mediatek.c
118
119 static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
120int duty_ns, int period_ns)
121 {
122 struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
> 123 struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
124 u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH,
125 reg_thres = PWMTHRES;
126 u64 resolution;
127 int ret;
128
129 ret = mtk_pwm_clk_enable(chip, pwm);
130 if (ret < 0)
131 return ret;
132
133 /* Using resolution in picosecond gets accuracy higher */
134 resolution = (u64)NSEC_PER_SEC * 1000;
135 do_div(resolution, clk_get_rate(clk));
136
137 cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000,
resolution);
138 while (cnt_period > 8191) {
139 resolution *= 2;
140 clkdiv++;
141 cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns *
1000,
142 resolution);
143 }
144
145 if (clkdiv > PWM_CLK_DIV_MAX) {
146 mtk_pwm_clk_disable(chip, pwm);
147 dev_err(chip->dev, "period %d not supported\n",
period_ns);
148 return -EINVAL;
149 }
150
151 if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) {
152 /*
153 * PWM[4,5] has distinct offset for PWMDWIDTH and
PWMTHRES
154 * from the other PWMs on MT7623.
155 */
156 reg_width = PWM45DWIDTH_FIXUP;
157 reg_thres = PWM45THRES_FIXUP;
158 }
159
160 cnt_duty = DIV_ROUND_CLOSEST_ULL((u64)duty_ns * 1000,
resolution);
161 mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
162 mtk_pwm_writel(pc, pwm->hwpwm, reg_width, cnt_period);
163 mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, cnt_duty);
164
165 mtk_pwm_clk_disable(chip, pwm);
166
167 return 0;
168 }
169
170 static int mtk_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
171 {
172 struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
173 u32 value;
174 int ret;
175
176 ret = mtk_pwm_clk_enable(chip, pwm);
177 if (ret < 0)
178 return ret;
179
180 value = readl(pc->regs);
181 value |= BIT(pwm->hwpwm);
182 writel(value, pc->regs);
183
184 return 0;
185 }
186
187 static void mtk_pwm_disable(struct pwm_chip *chip, struct pwm_device
*pwm)
188 {
189 struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
190 u32 value;
191
192 value = readl(pc->regs);
193 value &= ~
Re: [PATCH] mm: Support memblock alloc on the exact node for sparse_buffer_init()
On 2019/9/18 14:51, Wei Yang wrote:
> On Wed, Sep 18, 2019 at 12:22:29PM +0800, Yunfeng Ye wrote:
>> Currently, when memblock_find_in_range_node() fail on the exact node, it
>> will use %NUMA_NO_NODE to find memblock from other nodes. At present,
>> the work is good, but when the large memory is insufficient and the
>> small memory is enough, we want to allocate the small memory of this
>> node first, and do not need to allocate large memory from other nodes.
>>
>> In sparse_buffer_init(), it will prepare large chunks of memory for page
>> structure. The page management structure requires a lot of memory, but
>> if the node does not have enough memory, it can be converted to a small
>> memory allocation without having to allocate it from other nodes.
>>
>> Add %MEMBLOCK_ALLOC_EXACT_NODE flag for this situation. Normally, the
>> behavior is the same with %MEMBLOCK_ALLOC_ACCESSIBLE, only that it will
>> not allocate from other nodes when a single node fails to allocate.
>>
>> If large contiguous block memory allocated fail in sparse_buffer_init(),
>> it will allocates small block memmory section by section later.
>>
>
> Looks this changes current behavior even it fall back to section based
> allocation.
>
When fall back to section allocation, it still use %MEMBLOCK_ALLOC_ACCESSIBLE
,I think the behavior is not change, Can you tell me the detail about the
changes. thanks.
>> Signed-off-by: Yunfeng Ye
>> ---
>> include/linux/memblock.h | 1 +
>> mm/memblock.c| 3 ++-
>> mm/sparse.c | 2 +-
>> 3 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>> index f491690..9a81d9c 100644
>> --- a/include/linux/memblock.h
>> +++ b/include/linux/memblock.h
>> @@ -339,6 +339,7 @@ static inline int memblock_get_region_node(const struct
>> memblock_region *r)
>> #define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0)
>> #define MEMBLOCK_ALLOC_ACCESSIBLE0
>> #define MEMBLOCK_ALLOC_KASAN 1
>> +#define MEMBLOCK_ALLOC_EXACT_NODE 2
>>
>> /* We are using top down, so it is safe to use 0 here */
>> #define MEMBLOCK_LOW_LIMIT 0
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 7d4f61a..dbd52c3c 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -277,6 +277,7 @@ static phys_addr_t __init_memblock
>> memblock_find_in_range_node(phys_addr_t size,
>>
>> /* pump up @end */
>> if (end == MEMBLOCK_ALLOC_ACCESSIBLE ||
>> +end == MEMBLOCK_ALLOC_EXACT_NODE ||
>> end == MEMBLOCK_ALLOC_KASAN)
>> end = memblock.current_limit;
>>
>> @@ -1365,7 +1366,7 @@ static phys_addr_t __init
>> memblock_alloc_range_nid(phys_addr_t size,
>> if (found && !memblock_reserve(found, size))
>> goto done;
>>
>> -if (nid != NUMA_NO_NODE) {
>> +if (end != MEMBLOCK_ALLOC_EXACT_NODE && nid != NUMA_NO_NODE) {
>> found = memblock_find_in_range_node(size, align, start,
>> end, NUMA_NO_NODE,
>> flags);
>> diff --git a/mm/sparse.c b/mm/sparse.c
>> index 72f010d..828db46 100644
>> --- a/mm/sparse.c
>> +++ b/mm/sparse.c
>> @@ -477,7 +477,7 @@ static void __init sparse_buffer_init(unsigned long
>> size, int nid)
>> sparsemap_buf =
>> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
>> addr,
>> -MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>> +MEMBLOCK_ALLOC_EXACT_NODE, nid);
>> sparsemap_buf_end = sparsemap_buf + size;
>> }
>>
>> --
>> 2.7.4.huawei.3
>>
>
Regression in dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") [Was: Regression in fd5f7cde1b85 ("...")]
Hello Sergey,
On Wed, Sep 18, 2019 at 10:30:32AM +0900, Sergey Senozhatsky wrote:
> On (09/17/19 16:10), Uwe Kleine-König wrote:
> > Hello,
> >
> > Today it saw sysrq on an UART driven by drivers/tty/serial/imx.c report
> > a lockdep issue. Bisecting pointed to
> >
> > fd5f7cde1b85 ("printk: Never set console_may_schedule in
> > console_trylock()")
>
> Hmmm...
>
> I don't see how this patch can affect anything. It simply
> disables preemption in printk().
I rechecked and indeed fd5f7cde1b85's parent has the problem, too, so I
did a mistake during my bisection :-|
Redoing the bisection (a bit quicker this time) points to
dbdda842fe96 ("printk: Add console owner and waiter logic to load balance
console writes")
Sorry for the confusion.
> > When I type t I get:
> >
> > [ 87.940104] sysrq: SysRq : This sysrq operation is disabled.
> > [ 87.948752]
> > [ 87.948772] ==
> > [ 87.948787] WARNING: possible circular locking dependency detected
> > [ 87.948798] 4.14.0-12954-gfd5f7cde1b85 #26 Not tainted
> > [ 87.948813] --
> > [ 87.948822] swapper/0 is trying to acquire lock:
> > [ 87.948829] (console_owner){-...}, at: []
> > console_unlock+0x110/0x598
> > [ 87.948861]
> > [ 87.948869] but task is already holding lock:
> > [ 87.948874] (&port_lock_key){-.-.}, at: []
> > imx_rxint+0x2c/0x290
> > [ 87.948902]
> > [ 87.948911] which lock already depends on the new lock.
> > [ 87.948917]
> > [ 87.948923]
> > [ 87.948932] the existing dependency chain (in reverse order) is:
> > [ 87.948938]
> > [ 87.948943] -> #1 (&port_lock_key){-.-.}:
> > [ 87.948975]_raw_spin_lock_irqsave+0x5c/0x70
> > [ 87.948983]imx_console_write+0x138/0x15c
> > [ 87.948991]console_unlock+0x204/0x598
> > [ 87.949000]register_console+0x21c/0x3e8
> > [ 87.949008]uart_add_one_port+0x3e4/0x4dc
> > [ 87.949019]platform_drv_probe+0x3c/0x78
> > [ 87.949027]driver_probe_device+0x25c/0x47c
> > [ 87.949035]__driver_attach+0xec/0x114
> > [ 87.949044]bus_for_each_dev+0x80/0xb0
> > [ 87.949054]bus_add_driver+0x1d4/0x264
> > [ 87.949062]driver_register+0x80/0xfc
> > [ 87.949069]imx_serial_init+0x28/0x48
> > [ 87.949078]do_one_initcall+0x44/0x18c
> > [ 87.949087]kernel_init_freeable+0x11c/0x1cc
> > [ 87.949095]kernel_init+0x10/0x114
> > [ 87.949103]ret_from_fork+0x14/0x30
>
> This is "normal" locking path
>
> console_sem -> port->lock
>
> printk()
>lock console_sem
> imx_console_write()
> lock port->lock
>
> > [ 87.949113] -> #0 (console_owner){-...}:
> > [ 87.949145]lock_acquire+0x100/0x23c
> > [ 87.949154]console_unlock+0x1a4/0x598
> > [ 87.949162]vprintk_emit+0x1a4/0x45c
> > [ 87.949171]vprintk_default+0x28/0x30
> > [ 87.949180]printk+0x28/0x38
> > [ 87.949189]__handle_sysrq+0x1c4/0x244
> > [ 87.949196]imx_rxint+0x258/0x290
> > [ 87.949206]imx_int+0x170/0x178
> > [ 87.949216]__handle_irq_event_percpu+0x78/0x418
> > [ 87.949225]handle_irq_event_percpu+0x24/0x6c
> > [ 87.949233]handle_irq_event+0x40/0x64
> > [ 87.949242]handle_level_irq+0xb4/0x138
> > [ 87.949252]generic_handle_irq+0x28/0x3c
> > [ 87.949261]__handle_domain_irq+0x50/0xb0
> > [ 87.949269]avic_handle_irq+0x3c/0x5c
> > [ 87.949277]__irq_svc+0x6c/0xa4
> > [ 87.949287]arch_cpu_idle+0x30/0x40
> > [ 87.949297]arch_cpu_idle+0x30/0x40
> > [ 87.949305]do_idle+0xa0/0x104
> > [ 87.949313]cpu_startup_entry+0x14/0x18
> > [ 87.949323]start_kernel+0x30c/0x368
>
> This one is a "reverse" locking path...
>
> port->lock -> console_sem
>
> There is more to it:
>
> imxint()
> lock port->lock
>uart_handle_sysrq_char()
> handle_sysrq()
> printk()
> lock conosole_sem
>imx_console_write()
> lock port->lock [boom]
>
> This path re-enters serial driver. But it doesn't deadlock, because
> uart_handle_sysrq_char() sets a special flag port->sysrq, and serial
> consoles are expected to make sure that they don't lock port->lock
> in this case. Otherwise we will kill the system:
>
> void serial_console_write(...)
> {
> ...
> if (sport->port.sysrq)
> locked = 0;
> else if (oops_in_progress)
> locked = spin_trylock_irqsave(&sport->port.lock, flags);
> else
> spin_lock_irqsave(&sport->port.lock, flags);
> ...
> }
>
> So I'd say that lockdep is correct, but there are several hacks which
> prevent actual deadlock.
Just to make sure, I got you right: With the way lockdep works it is
ri
Re: threads-max observe limits
On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote:
> >>
> >> On 9/17/19 12:03 PM, Michal Hocko wrote:
> >> > Hi,
> >> > I have just stumbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max
> >> > observe limits") and I am really wondering what is the motivation behind
> >> > the patch. We've had a customer noticing the threads_max autoscaling
> >> > differences btween 3.12 and 4.4 kernels and wanted to override the auto
> >> > tuning from the userspace, just to find out that this is not possible.
> >>
> >> set_max_threads() sets the upper limit (max_threads_suggested) for
> >> threads such that at a maximum 1/8th of the total memory can be occupied
> >> by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB
> >> system this results in 254313 threads.
> >
> > This is quite arbitrary, isn't it? What would happen if the limit was
> > twice as large?
> >
> >> With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> >> a user cannot set an arbitrarily high number for
> >> /proc/sys/kernel/threads-max which could lead to a system stalling
> >> because the thread headers occupy all the memory.
> >
> > This is still a decision of the admin to make. You can consume the
> > memory by other means and that is why we have measures in place. E.g.
> > memcg accounting.
> >
> >> When developing the patch I remarked that on a system where memory is
> >> installed dynamically it might be a good idea to recalculate this limit.
> >> If you have a system that boots with let's say 8 GiB and than
> >> dynamically installs a few TiB of RAM this might make sense. But such a
> >> dynamic update of thread_max_suggested was left out for the sake of
> >> simplicity.
> >>
> >> Anyway if more than 100,000 threads are used on a system, I would wonder
> >> if the software should not be changed to use thread-pools instead.
> >
> > You do not change the software to overcome artificial bounds based on
> > guessing.
> >
> > So can we get back to the justification of the patch. What kind of
> > real life problem does it solve and why is it ok to override an admin
> > decision?
> > If there is no strong justification then the patch should be reverted
> > because from what I have heard it has been noticed and it has broken
> > a certain deployment. I am not really clear about technical details yet
> > but it seems that there are workloads that believe they need to touch
> > this tuning and complain if that is not possible.
>
> Taking a quick look myself.
>
> I am completely mystified by both sides of this conversation.
>
> a) The logic to set the default number of threads in a system
>has not changed since 2.6.12-rc2 (the start of the git history).
>
> The implementation has changed but we should still get the same
> value. So anyone seeing threads_max autoscaling differences
> between kernels is either seeing a bug in the rewritten formula
> or something else weird is going on.
>
> Michal is it a very small effect your customers are seeing?
> Is it another bug somewhere else?
I am still trying to get more information. Reportedly they see a
different auto tuned limit between two kernel versions which results in
an applicaton complaining. As already mentioned this might be a side
effect of something else and this is not yet fully analyzed. My main
point for bringing up this discussion is ...
> b) Not being able to bump threads_max to the physical limit of
>the machine is very clearly a regression.
... exactly this part. The changelog of the respective patch doesn't
really exaplain why it is needed except of "it sounds like a good idea
to be consistent".
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] extcon-intel-cht-wc: Don't reset USB data connection at probe
On Wed, Sep 18, 2019 at 2:04 AM Yauhen Kharuzhy wrote:
>
> On Tue, Sep 17, 2019 at 02:13:22PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 17, 2019 at 12:15:36AM +0300, Yauhen Kharuzhy wrote:
> > > Intel Cherry Trail Whiskey Cove extcon driver connect USB data lines to
> > > PMIC at driver probing for further charger detection. This causes reset of
> > > USB data sessions and removing all devices from bus. If system was
> > > booted from Live CD or USB dongle, this makes system unusable.
> > >
> > > Check if USB ID pin is floating and re-route data lines in this case
> > > only, don't touch otherwise.
> >
> > > + ret = regmap_read(ext->regmap, CHT_WC_PWRSRC_STS, &pwrsrc_sts);
> > > + if (ret) {
> > > + dev_err(ext->dev, "Error reading pwrsrc status: %d\n", ret);
> > > + goto disable_sw_control;
> > > + }
> > > +
> > > + id = cht_wc_extcon_get_id(ext, pwrsrc_sts);
> >
> > We have second implementation of this. Would it make sense to split to some
> > helper?
>
> Do you mean the combination of regmap_read(...CHT_WC_PWRSRC_STS,
> &pwrsrc_sts) with cht_wc_extcon_get_id()?
Yes.
> In the cht_wc_extcon_pwrsrc_event() function the pwrsrc_sts is checked
> for other bits also, so separation of PWRSRC_STS read and id calculation
> to one routine will cause non-clear function calls like as
> get_powersrc_and_check_id(..., &powersrc_sts, &id) which is not looks
> better than current code duplication.
I see. Thanks for answer.
> Or we need to spend some time for
> refactoring and testing of cht_wc_extcon_pwrsrc_event() code.
Perhaps, In any case I'm not objecting of the current approach.
--
With Best Regards,
Andy Shevchenko
SFConservancy attacks RMS. - SFConservancy: GO TO HELL
Software Freedom Conservancy >Verified account @conservancy The fight for diversity, equality and inclusion is the fight for software freedom. Our movement will only be successful if it includes everyone. RMS does not speak for these values. twitter.com/conservancy/status/1173603417769545734 Dear SFConservancy. You might not understand the lawyer-speak, being headed for the longest time by a mere techie (ie: one who thinks arrays are a "necessary language tool"), but Free licenses are Revocable from free-takers. Keep attacking the men who created the software and the men will eventually move to revoke your gratis licenses of their copyrighted works and burn the legal framework of Free Software to the ground (a framework that relies mostly on ignorance of the vagaries of copyright and licensing law). Look, Free Software world, I told you a decade ago NOT to invite random women and non-techies into your world: you will gain nothing and they will set themselves up as gate keepers to your community. They have done so. They just kicked out RMS from his own foundation. Who knows what "GPLv4" will contain now. (Not that it matters: you can still revoke free licenses from free-takers regardless of what "terms" were "agreed upon" (no consideration on the part of the taker means no contractual rights to hold the distributee to)) RMS said absolutely nothing wrong: just things White Women and their golem-like white "men" find offensive. (YHWH allows child brides, including in cases of rape (taphas): Devarim chapter 22, verse 28 (Hebrew Masoretic Text: Na'ar (child), Greek Septuagint: Padia (child, root word for paedophile), Latin Vulgate: Puella) It's time to move Free Software and OpenSource out of America. America is the global enemy of all men anyway: why deal with the savages that slaughter countless innocents in the near-east because "they marry young girls, BETTER A MILLSTONE!" etc? Why associate yourself with such evil torturers and murderers that are the Proud American (White) Man (and his female Masters)? Regarding threats to "CoC" you. - You do have recourse - license rescission lkml.org/lkml/2019/5/9/434 For easy to read by lay-people discussions on this topic: lkml.org/lkml/2019/5/4/334 lkml.org/lkml/2019/5/3/698 lkml.org/lkml/2018/9/20/444 For legal articles and treatises that agree: no consideration from GPL free-taker, no contract, revocable by the copyright holder: scholarship.law.duke.edu/faculty_scholarship/1857/ www.amazon.com/Open-Source-Licensing-Software-Intellectual/dp/0131487876 papers.ssrn.com/sol3/papers.cfm?abstract_id=243237
Re: [PATCH] perf cgroups: Don't rotate events for cgroups unnecessarily
On Fri, Aug 23, 2019 at 6:33 PM Peter Zijlstra wrote: > > On Fri, Aug 23, 2019 at 06:26:34PM +0530, Ganapatrao Kulkarni wrote: > > On Fri, Aug 23, 2019 at 5:29 PM Peter Zijlstra wrote: > > > On Fri, Aug 23, 2019 at 04:13:46PM +0530, Ganapatrao Kulkarni wrote: > > > > > > > We are seeing regression with our uncore perf driver(Marvell's > > > > ThunderX2, ARM64 server platform) on 5.3-Rc1. > > > > After bisecting, it turned out to be this patch causing the issue. > > > > > > Funnily enough; the email you replied to didn't contain a patch. > > > > Hmm sorry, not sure why the patch is clipped-off, I see it in my inbox. > > Your email is in a random spot of the discussion for me. At least it was > fairly easy to find the related patch. > > > > > Test case: > > > > Load module and run perf for more than 4 events( we have 4 counters, > > > > event multiplexing takes place for more than 4 events), then unload > > > > module. > > > > With this sequence of testing, the system hangs(soft lockup) after 2 > > > > or 3 iterations. Same test runs for hours on 5.2. > > > > > > > > while [ 1 ] > > > > do > > > > rmmod thunderx2_pmu > > > > modprobe thunderx2_pmu > > > > perf stat -a -e \ > > > > uncore_dmc_0/cnt_cycles/,\ > > > > uncore_dmc_0/data_transfers/,\ > > > > uncore_dmc_0/read_txns/,\ > > > > uncore_dmc_0/config=0xE/,\ > > > > uncore_dmc_0/write_txns/ sleep 1 > > > > sleep 2 > > > > done > > > > > > Can you reproduce without the module load+unload? I don't think people > > > routinely unload modules. > > > > The issue wont happen, if module is not unloaded/reloaded. > > IMHO, this could be potential bug! > > Does the softlockup give a useful stacktrace? I don't have a thunderx2 > so I cannot reproduce. Sorry for the late reply, below is the dump that i am getting, when i hit the softlockup. Any suggestions to debug this further? sequence of commands, which leads to this lockup, insmod thunderx2_pmu.ko perf stat -e \ uncore_dmc_0/cnt_cycles/,\ uncore_dmc_0/data_transfers/,\ uncore_dmc_0/read_txns/,\ uncore_dmc_0/config=0xE/,\ uncore_dmc_0/write_txns/\ rmmod thunderx2_pmu insmod thunderx2_pmu.ko root@SBR-26>~>> [ 1065.946772] watchdog: BUG: soft lockup - CPU#117 stuck for 22s! [perf:5206] [ 1065.953722] Modules linked in: thunderx2_pmu(OE) nls_iso8859_1 joydev input_leds bridge ipmi_ssif ipmi_devintf stp llc ipmi_msghandler sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 multipat h linear aes_ce_blk hid_generic aes_ce_cipher usbhid uas usb_storage hid ast i2c_algo_bit drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm i40e i2c_smbus bnx2x crct10dif_ce g hash_ce e1000e sha2_ce mpt3sas nvme sha256_arm64 ptp ahci raid_class sha1_ce nvme_core scsi_transport_sas mdio libahci pps_core libcrc32c gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm6 4 [last unloaded: thunderx2_pmu] [ 1066.029640] CPU: 117 PID: 5206 Comm: perf Tainted: G OE 5.3.0+ #160 [ 1066.037109] Hardware name: Cavium Inc. Saber/Saber, BIOS TX2-FW-Release-7.2-build_08-0-g14f8c5bf8a 12/18/2018 [ 1066.047009] pstate: 2049 (nzCv daif +PAN -UAO) [ 1066.051799] pc : smp_call_function_single+0x198/0x1b0 [ 1066.056838] lr : smp_call_function_single+0x16c/0x1b0 [ 1066.061875] sp : fc00434cfc50 [ 1066.065177] x29: fc00434cfc50 x28: [ 1066.070475] x27: febed4d2d952 x26: d4d2d800 [ 1066.075774] x25: fddf5da1e240 x24: 0001 [ 1066.081073] x23: fc00434cfd38 x22: fc001026adb8 [ 1066.086371] x21: x20: fc0011843000 [ 1066.091669] x19: fc00434cfca0 x18: [ 1066.096968] x17: x16: [ 1066.102266] x15: x14: [ 1066.107564] x13: x12: 0020 [ 1066.112862] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f [ 1066.118161] x9 : x8 : febed44ec5e8 [ 1066.123459] x7 : x6 : fc00434cfca0 [ 1066.128757] x5 : fc00434cfca0 x4 : 0001 [ 1066.134055] x3 : fc00434cfcb8 x2 : [ 1066.139353] x1 : 0003 x0 : [ 1066.144652] Call trace: [ 1066.147088] smp_call_function_single+0x198/0x1b0 [ 1066.151784] perf_install_in_context+0x1b4/0x1d8 [ 1066.156394] __se_sys_perf_event_open+0x634/0xa68 [ 1066.161089] __arm64_sys_perf_event_open+0x1c/0x28 [ 1066.165881] el0_svc_common.constprop.0+0x78/0x168 [ 1066.170660] el0_svc_handler+0x34/0x90 [ 1066.174399] el0_svc+0x8/0xc [ 1100.985033] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 1100.990944] rcu: 0-...0: (4 ticks this GP) idle=bb6/0/0x1 softirq=2178/2178 fqs=7365 [ 1100.998864]
Re: [GIT PULL] LED updates for 5.4-rc1
On Wed, Sep 18, 2019 at 10:16 AM Linus Torvalds wrote: > > On Tue, Sep 17, 2019 at 6:13 PM Linus Torvalds > wrote: > > > > So this is fine and I've pulled it, > > Famous last words. I now get a new warning: > > drivers/i2c/i2c-core-acpi.c:347:12: warning: > ‘i2c_acpi_find_match_adapter’ defined but not used [-Wunused-function] > 347 | static int i2c_acpi_find_match_adapter(struct device *dev, > const void *data) > |^~~ > > with this pull request. I'll have to look at it after dinner. > > Linus One of those *device core* patch broke i2c ACPI, which has been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/i2c/i2c-core-acpi.c?id=644bf60088955421051e716ab9c8fe7fb7997fd7 As I read above the merge commit didn't take this patch. Solution might be to merge this PR after corresponding bundle of device core stuff. -- With Best Regards, Andy Shevchenko
Re: [RFC PATCH] memalloc_noio: update the comment to make it cleaner
On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
> From: Xiubo Li
>
> The GFP_NOIO means all further allocations will implicitly drop
> both __GFP_IO and __GFP_FS flags and so they are safe for both the
> IO critical section and the the critical section from the allocation
> recursion point of view. Not only the __GFP_IO, which a bit confusing
> when reading the code or using the save/restore pair.
Historically GFP_NOIO has always implied GFP_NOFS as well. I can imagine
that this might come as an surprise for somebody not familiar with the
code though. I am wondering whether your update of the documentation
would be better off at __GFP_FS, __GFP_IO resp. GFP_NOFS, GFP_NOIO level.
This interface is simply a way to set a scoped NO{IO,FS} context.
> Signed-off-by: Xiubo Li
> ---
> include/linux/sched/mm.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 4a7944078cc3..9bdc97e52de1 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -211,10 +211,11 @@ static inline void fs_reclaim_release(gfp_t gfp_mask) {
> }
> * memalloc_noio_save - Marks implicit GFP_NOIO allocation scope.
> *
> * This functions marks the beginning of the GFP_NOIO allocation scope.
> - * All further allocations will implicitly drop __GFP_IO flag and so
> - * they are safe for the IO critical section from the allocation recursion
> - * point of view. Use memalloc_noio_restore to end the scope with flags
> - * returned by this function.
> + * All further allocations will implicitly drop __GFP_IO and __GFP_FS
> + * flags and so they are safe for both the IO critical section and the
> + * the critical section from the allocation recursion point of view. Use
> + * memalloc_noio_restore to end the scope with flags returned by this
> + * function.
> *
> * This function is safe to be used from any context.
> */
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
[PATCH] genirq: modify the comment for irq_desc
commit 0c6f8a8b917a ("genirq: Remove compat code") deleted the @status
member of irq_desc, but forgot to update the comment.
Signed-off-by: Yunfeng Ye
---
include/linux/irqdesc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index d6e2ab5..8f2820c 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -24,7 +24,7 @@
* @handle_irq:highlevel irq-events handler
* @preflow_handler: handler called before the flow handler (currently used
by sparc)
* @action:the irq action chain
- * @status:status information
+ * @status_use_accessors: status information
* @core_internal_state__do_not_mess_with_it: core internal status information
* @depth: disable-depth, for nested irq_disable() calls
* @wake_depth:enable depth, for multiple irq_set_irq_wake()
callers
--
1.8.3.1
Re: [GIT PULL] LED updates for 5.4-rc1
On Wed, Sep 18, 2019 at 10:24 AM Linus Torvalds
wrote:
>
> On Tue, Sep 17, 2019 at 6:14 PM Linus Torvalds
> wrote:
> >
> > Famous last words. I now get a new warning:
> >
> > drivers/i2c/i2c-core-acpi.c:347:12: warning:
> > ‘i2c_acpi_find_match_adapter’ defined but not used [-Wunused-function]
>
> Commit 00500147cbd3 ("drivers: Introduce device lookup variants by
> ACPI_COMPANION device") removed the use of that matching function, but
> didn't remove the function.
>
> It also removed the use of i2c_acpi_find_match_device(), but in that
> case it _did_ remove the function.
I hope you have a chance to read my previous email.
We still need that function.
--
With Best Regards,
Andy Shevchenko
Re: [RFC PATCH v2] mm: initialize struct pages reserved by ZONE_DEVICE driver.
On 09.09.19 09:46, David Hildenbrand wrote:
> On 09.09.19 07:48, Toshiki Fukasawa wrote:
>> On 2019/09/06 19:35, David Hildenbrand wrote:
>>> On 06.09.19 12:02, Toshiki Fukasawa wrote:
Thank you for your feedback.
On 2019/09/06 17:45, David Hildenbrand wrote:
> On 06.09.19 10:09, Toshiki Fukasawa wrote:
>> A kernel panic is observed during reading
>> /proc/kpage{cgroup,count,flags} for first few pfns allocated by
>> pmem namespace:
>>
>> BUG: unable to handle page fault for address: fffe
>> [ 114.495280] #PF: supervisor read access in kernel mode
>> [ 114.495738] #PF: error_code(0x) - not-present page
>> [ 114.496203] PGD 17120e067 P4D 17120e067 PUD 171210067 PMD 0
>> [ 114.496713] Oops: [#1] SMP PTI
>> [ 114.497037] CPU: 9 PID: 1202 Comm: page-types Not tainted 5.3.0-rc1
>> [ 114.497621] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
>> [ 114.498706] RIP: 0010:stable_page_flags+0x27/0x3f0
>> [ 114.499142] Code: 82 66 90 66 66 66 66 90 48 85 ff 0f 84 d1 03 00 00
>> 41 54 55 48 89 fd 53 48 8b 57 08 48 8b 1f 48 8d 42 ff 83 e2 01 48 0f 44
>> c7 <48> 8b 00 f6 c4 02 0f 84 57 03 00 00 45 31 e4 48 8b 55 08 48 89 ef
>> [ 114.500788] RSP: 0018:a5e601a0fe60 EFLAGS: 00010202
>> [ 114.501373] RAX: fffe RBX: RCX:
>>
>> [ 114.502009] RDX: 0001 RSI: 7ffca13a7310 RDI:
>> d0748900
>> [ 114.502637] RBP: d0748900 R08: 0001 R09:
>>
>> [ 114.503270] R10: R11: R12:
>> 0024
>> [ 114.503896] R13: 0008 R14: 7ffca13a7310 R15:
>> a5e601a0ff08
>> [ 114.504530] FS: 7f0266c7f540() GS:962dbbac()
>> knlGS:
>> [ 114.505245] CS: 0010 DS: ES: CR0: 80050033
>> [ 114.505754] CR2: fffe CR3: 00023a204000 CR4:
>> 06e0
>> [ 114.506401] Call Trace:
>> [ 114.506660] kpageflags_read+0xb1/0x130
>> [ 114.507051] proc_reg_read+0x39/0x60
>> [ 114.507387] vfs_read+0x8a/0x140
>> [ 114.507686] ksys_pread64+0x61/0xa0
>> [ 114.508021] do_syscall_64+0x5f/0x1a0
>> [ 114.508372] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 114.508844] RIP: 0033:0x7f0266ba426b
>>
>> The first few pages of ZONE_DEVICE expressed as the range
>> (altmap->base_pfn) to (altmap->base_pfn + altmap->reserve) are
>> skipped by struct page initialization. Some pfn walkers like
>> /proc/kpage{cgroup, count, flags} can't handle these uninitialized
>> struct pages, which causes the error.
>>
>> In previous discussion, Dan seemed to have concern that the struct
>> page area of some pages indicated by vmem_altmap->reserve may not
>> be allocated. (See
>> https://lore.kernel.org/lkml/capcyv4i5fjtonpbxnctzvt+e6rqyow0jrqwsfuxaa62lsuv...@mail.gmail.com/)
>> However, arch_add_memory() called by devm_memremap_pages() allocates
>> struct page area for pages containing addresses in the range
>> (res.start) to (res.start + resource_size(res)), which include the
>> pages indicated by vmem_altmap->reserve. If I read correctly, it is
>> allocated as requested at least on x86_64. Also, memmap_init_zone()
>> initializes struct pages in the same range.
>> So I think the struct pages should be initialized.>
>
> For !ZONE_DEVICE memory, the memmap is valid with SECTION_IS_ONLINE -
> for the whole section. For ZONE_DEVICE memory we have no such
> indication. In any section that is !SECTION_IS_ONLINE and
> SECTION_MARKED_PRESENT, we could have any subsections initialized. >
> The only indication I am aware of is pfn_zone_device_reserved() - which
> seems to check exactly what you are trying to skip here.
>
> Can't you somehow use pfn_zone_device_reserved() ? Or if you considered
> that already, why did you decide against it?
No, in current approach this function is no longer needed.
The reason why we change the approach is that all pfn walkers
have to be aware of the uninitialized struct pages.
>>>
>>> We should use the same strategy for all pfn walkers then (effectively
>>> get rid of pfn_zone_device_reserved() if that's what we want).
>>
>> True, but this patch replaces "/proc/kpageflags: do not use uninitialized
>> struct pages". If we initialize the uninitialized struct pages, no pfn walker
>> will need to be aware of them.
>
> So the function should go.
>
>>
>>>
As for SECTION_IS_ONLINE, I'm not sure now.
I will look into it next week.
>>>
>>> SECTION_IS_ONLINE does currently not apply to ZONE_DEVICE and due to
>>> sub-section support for ZONE_DEVICE, it cannot easily be reused.
>>>
>> It s
[PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode
Macronix AD series support using power down command to
enter a minimum power consumption state.
MTD default _suspend/_resume function replacement by
manufacturer postponed initialization.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/nand_macronix.c | 78 +++-
1 file changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 991c636..99a7b2e 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -15,6 +15,8 @@
#define MXIC_BLOCK_PROTECTION_ALL_LOCK 0x38
#define MXIC_BLOCK_PROTECTION_ALL_UNLOCK 0x0
+#define NAND_CMD_POWER_DOWN 0xB9
+
struct nand_onfi_vendor_macronix {
u8 reserved;
u8 reliability_func;
@@ -78,6 +80,12 @@ static void macronix_nand_onfi_init(struct nand_chip *chip)
"MX30UF4G28AC",
};
+static const char * const nand_power_down[] = {
+ "MX30LF1G28AD",
+ "MX30LF2G28AD",
+ "MX30LF4G28AD",
+};
+
static void macronix_nand_fix_broken_get_timings(struct nand_chip *chip)
{
unsigned int i;
@@ -144,8 +152,64 @@ static int mxic_nand_unlock(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
return ret;
}
+int nand_power_down_op(struct nand_chip *chip)
+{
+ int ret;
+
+ if (nand_has_exec_op(chip)) {
+ struct nand_op_instr instrs[] = {
+ NAND_OP_CMD(NAND_CMD_POWER_DOWN, 0),
+ };
+
+ struct nand_operation op = NAND_OPERATION(chip->cur_cs, instrs);
+
+ ret = nand_exec_op(chip, &op);
+ if (ret)
+ return ret;
+
+ } else {
+ chip->legacy.cmdfunc(chip, NAND_CMD_POWER_DOWN, -1, -1);
+ }
+
+ return 0;
+}
+
+static int mxic_nand_suspend(struct mtd_info *mtd)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+
+ mutex_lock(&chip->lock);
+
+ nand_select_target(chip, 0);
+ nand_power_down_op(chip);
+ nand_deselect_target(chip);
+
+ chip->suspend = 1;
+ mutex_unlock(&chip->lock);
+
+ return 0;
+}
+
+static void mxic_nand_resume(struct mtd_info *mtd)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+
+ mutex_lock(&chip->lock);
+ // toggle #CS pin to resume NAND device
+ nand_select_target(chip, 0);
+ ndelay(20);
+ nand_deselect_target(chip);
+
+ if (chip->suspend)
+ chip->suspended = 0;
+ else
+ pr_err("%s call for a chip which is not in suspended state\n",
+ __func__);
+ mutex_unlock(&chip->lock);
+}
+
/*
- * Macronix AC series support using SET/GET_FEATURES to change
+ * Macronix AC and AD series support using SET/GET_FEATURES to change
* Block Protection and Unprotection.
*
* MTD call-back function replacement by manufacturer postponed
@@ -163,6 +227,18 @@ static void macronix_nand_post_init(struct nand_chip *chip)
}
}
+ for (i = 0; i < ARRAY_SIZE(nand_power_down); i++) {
+ if (!strcmp(nand_power_down[i], chip->parameters.model)) {
+ blockprotected = 1;
+ break;
+ }
+ }
+
+ if (i < ARRAY_SIZE(nand_power_down)) {
+ mtd->_suspend = mxic_nand_suspend;
+ mtd->_resume = mxic_nand_resume;
+ }
+
if (blockprotected && chip->parameters.supports_set_get_features) {
bitmap_set(chip->parameters.set_feature_list,
ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
--
1.9.1
[PATCH RFC 1/3] mtd: rawnand: Add support manufacturer postponed initialization
Manufacturer postponed initialization is for MTD default call-back
function replacement for vendor soecific operation, i.e.,
_lock/_unlock, _suspend/_resume and so on.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/internals.h | 4
drivers/mtd/nand/raw/nand_base.c | 19 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/mtd/nand/raw/internals.h b/drivers/mtd/nand/raw/internals.h
index cba6fe7..505dd46 100644
--- a/drivers/mtd/nand/raw/internals.h
+++ b/drivers/mtd/nand/raw/internals.h
@@ -42,6 +42,9 @@
* is here to let vendor specific code release those resources.
* @fixup_onfi_param_page: apply vendor specific fixups to the ONFI parameter
*page. This is called after the checksum is verified.
+ * @post_init: postponed initialization is for MTD default call-back function
+ *replacement for vendor specific operation i.e., _lock/_unlock,
+ *_suspend/_resume and so on.
*/
struct nand_manufacturer_ops {
void (*detect)(struct nand_chip *chip);
@@ -49,6 +52,7 @@ struct nand_manufacturer_ops {
void (*cleanup)(struct nand_chip *chip);
void (*fixup_onfi_param_page)(struct nand_chip *chip,
struct nand_onfi_params *p);
+ void (*post_init)(struct nand_chip *chip);
};
/**
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 91f046d..7835b81 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4619,6 +4619,21 @@ static int nand_manufacturer_init(struct nand_chip *chip)
}
/*
+ * Manufacturer postponed initialization. This function is called for all NANDs
+ * whose MTD default call-back function replacement is needed.
+ * Manufacturer drivers should put all their specific postponed initialization
+ * code in their ->post_init() hook.
+ */
+static void nand_manufacturer_post_init(struct nand_chip *chip)
+{
+ if (!chip->manufacturer.desc || !chip->manufacturer.desc->ops ||
+ !chip->manufacturer.desc->ops->post_init)
+ return;
+
+ return chip->manufacturer.desc->ops->post_init(chip);
+}
+
+/*
* Manufacturer cleanup. This function is called for all NANDs including
* ONFI and JEDEC compliant ones.
* Manufacturer drivers should put all their specific cleanup code in their
@@ -5812,6 +5827,10 @@ static int nand_scan_tail(struct nand_chip *chip)
goto err_nanddev_cleanup;
}
+ nand_select_target(chip, 0);
+ nand_manufacturer_post_init(chip);
+ nand_deselect_target(chip);
+
/* Check, if we should skip the bad block table scan */
if (chip->options & NAND_SKIP_BBTSCAN)
return 0;
--
1.9.1
[PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function
Macronix AC series support using SET/GET_FEATURES to change
Block Protection and Unprotection.
MTD default _lock/_unlock function replacement by manufacturer
postponed initialization.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/nand_macronix.c | 80 +---
1 file changed, 75 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 58511ae..991c636 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -11,6 +11,10 @@
#define MACRONIX_READ_RETRY_BIT BIT(0)
#define MACRONIX_NUM_READ_RETRY_MODES 6
+#define ONFI_FEATURE_ADDR_MXIC_PROTECTION 0xA0
+#define MXIC_BLOCK_PROTECTION_ALL_LOCK 0x38
+#define MXIC_BLOCK_PROTECTION_ALL_UNLOCK 0x0
+
struct nand_onfi_vendor_macronix {
u8 reserved;
u8 reliability_func;
@@ -57,10 +61,7 @@ static void macronix_nand_onfi_init(struct nand_chip *chip)
* the timings unlike what is declared in the parameter page. Unflag
* this feature to avoid unnecessary downturns.
*/
-static void macronix_nand_fix_broken_get_timings(struct nand_chip *chip)
-{
- unsigned int i;
- static const char * const broken_get_timings[] = {
+static const char * const broken_get_timings[] = {
"MX30LF1G18AC",
"MX30LF1G28AC",
"MX30LF2G18AC",
@@ -75,7 +76,11 @@ static void macronix_nand_fix_broken_get_timings(struct
nand_chip *chip)
"MX30UF4G18AC",
"MX30UF4G16AC",
"MX30UF4G28AC",
- };
+};
+
+static void macronix_nand_fix_broken_get_timings(struct nand_chip *chip)
+{
+ unsigned int i;
if (!chip->parameters.supports_set_get_features)
return;
@@ -105,6 +110,71 @@ static int macronix_nand_init(struct nand_chip *chip)
return 0;
}
+static int mxic_nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
+ int ret;
+
+ feature[0] = MXIC_BLOCK_PROTECTION_ALL_LOCK;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("%s all blocks failed\n", __func__);
+
+ return ret;
+}
+
+static int mxic_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
+ int ret;
+
+ feature[0] = MXIC_BLOCK_PROTECTION_ALL_UNLOCK;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("%s all blocks failed\n", __func__);
+
+ return ret;
+}
+
+/*
+ * Macronix AC series support using SET/GET_FEATURES to change
+ * Block Protection and Unprotection.
+ *
+ * MTD call-back function replacement by manufacturer postponed
+ * initialization.
+ */
+static void macronix_nand_post_init(struct nand_chip *chip)
+{
+ unsigned int i, blockprotected = 0;
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ for (i = 0; i < ARRAY_SIZE(broken_get_timings); i++) {
+ if (!strcmp(broken_get_timings[i], chip->parameters.model)) {
+ blockprotected = 1;
+ break;
+ }
+ }
+
+ if (blockprotected && chip->parameters.supports_set_get_features) {
+ bitmap_set(chip->parameters.set_feature_list,
+ ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
+ bitmap_set(chip->parameters.get_feature_list,
+ ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
+
+ mtd->_lock = mxic_nand_lock;
+ mtd->_unlock = mxic_nand_unlock;
+ }
+}
+
const struct nand_manufacturer_ops macronix_nand_manuf_ops = {
.init = macronix_nand_init,
+ .post_init = macronix_nand_post_init,
};
--
1.9.1
Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
On 09/13/2019 11:53 AM, Christophe Leroy wrote: > Fix build failure on powerpc. > > Fix preemption imbalance. > > Signed-off-by: Christophe Leroy > --- > mm/arch_pgtable_test.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c > index 8b4a92756ad8..f2b3c9ec35fa 100644 > --- a/mm/arch_pgtable_test.c > +++ b/mm/arch_pgtable_test.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void) > p4d_clear_tests(p4dp); > pgd_clear_tests(mm, pgdp); > > + pte_unmap(ptep); > + > pmd_populate_tests(mm, pmdp, saved_ptep); > pud_populate_tests(mm, pudp, saved_pmdp); > p4d_populate_tests(mm, p4dp, saved_pudp); > Hello Christophe, I am planning to fold this fix into the current patch and retain your Signed-off-by. Are you okay with it ? - Anshuman
Re: printk meeting at LPC
On 2019-09-18, Sergey Senozhatsky wrote: 2. A kernel thread will be created for each registered console, each responsible for being the sole printers to their respective consoles. With this, console printing is _fully_ decoupled from printk() callers. >>> >>> sysrq over serial? >>> >>> offloading this to kthread may be unreliable. >> >> But we also talked about an "emergency flush" which will not wait for >> the kthreads to finish and just output everything it can find in the >> printk buffers (expecting that the consoles have an "emergency" >> handler. We can add a sysrq to do an emergency flush. The problem with only a flush here is that the sysrq output may not fit in the ringbuffer (ftrace, for example). It probably makes more sense to have a switch to enter/exit "synchronous state", where all atomic consoles are flushed upon enter and all future printk's are synchronous on atomic consoles until exit. I expect sysrq to be the only valid use of "synchronous state" other than oops/panic. Although I suppose PeterZ would like a boot argument to always run the consoles in this state. > I agree that when consoles have ->atomic_write then it surely makes > sense to switch to emergency mode. I like the emergency state > approach, but I'm not sure how it can be completely invisible to the > rest of the system. Quoting John: > > : Unlike oops_in_progress, this state will not be visible to > : anything outside of the printk infrastructure. > > For instance, tty/sysrq must be able to switch printk emergency > on/off. The switch/flush _will_ be visible. But not the state. So, for example, it won't be possible for some random driver to determine if we are in an emergency state. (Well, I don't know if oops_in_progress will really disappear. But at least the printk/console stuff will no longer rely on it.) > We also figured out that some PM (hibernation/suspend/etc.) stages > (very early and/or very late ones) [2] also should have printk in > emergency mode, plus some other parts of the kernel [3]. > > [1] > https://lore.kernel.org/lkml/20170815025625.1977-4-sergey.senozhat...@gmail.com/ > [2] > https://lore.kernel.org/lkml/20170815025625.1977-7-sergey.senozhat...@gmail.com/ > [3] > https://lore.kernel.org/lkml/20170815025625.1977-8-sergey.senozhat...@gmail.com/ Thanks for bringing up that RFC thread again. I haven't looked at it in over a year. I will go through it again to see if there is anything I've overlooked. Particularly the suspend stuff. John Ogness
Re: [RFC 4/4] gpio: sifive: Add GPIO driver for SiFive SoCs
Hi,
On Wed, Oct 17, 2018 at 9:01 AM Atish Patra wrote:
>
> On 10/10/18 5:35 AM, Linus Walleij wrote:
> > Hi Atish,
> >
> > thanks for your patch!
> >
> > On Tue, Oct 9, 2018 at 8:51 PM Atish Patra wrote:
> >
> >> From: "Wesley W. Terpstra"
> >>
> >> Adds the GPIO driver for SiFive RISC-V SoCs.
> >>
> >> Signed-off-by: Wesley W. Terpstra
> >> [Atish: Various fixes and code cleanup]
> >> Signed-off-by: Atish Patra
> >
> > (...)
> >
> >> +config GPIO_SIFIVE
> >> + bool "SiFive GPIO support"
> >> + depends on OF_GPIO
> >> + select GPIOLIB_IRQCHIP
> >
> > I suggest to add
> > select GPIO_GENERIC as per below.
> >
> > Maybe select REGMAP_MMIO as well.
>
> ok.
>
> >
> >> + help
> >> + Say yes here to support the GPIO device on SiFive SoCs.
> >> +
> >
> >> +#include
> >> +#include
> >
> > Do you need these two? I think
> > will bring them in for you.
> >
>
> driver.h only brings chained_irq.h. of_irq.h is still required. Right ?
>
> >> +#include
> >
> > Are you using this?
>
> My bad. Left over from the old code. I will remove it.
>
> >
> >> +struct sifive_gpio {
> >> + raw_spinlock_t lock;
> >> + void __iomem*base;
> >> + struct gpio_chipgc;
> >> + unsigned long enabled;
> >
> > Since max GPIO is 32 why not use an u32 for this?
> >
>
> Sure.
>
> >> + unsigned inttrigger[MAX_GPIO];
> >> + unsigned intirq_parent[MAX_GPIO];
> >> + struct sifive_gpio *self_ptr[MAX_GPIO];
> >> +};
> >> +
> >> +static void sifive_assign_bit(void __iomem *ptr, unsigned int offset, int
> >> value)
> >> +{
> >> + /*
> >> +* It's frustrating that we are not allowed to use the device
> >> atomics
> >> +* which are GUARANTEED to be supported by this device on RISC-V
> >> +*/
> >> + u32 bit = BIT(offset), old = ioread32(ptr);
> >> +
> >> + if (value)
> >> + iowrite32(old | bit, ptr);
> >> + else
> >> + iowrite32(old & ~bit, ptr);
> >> +}
> >
> > This looks like a mask and set implementation, you are
> > essentially reinventing regmap MMIO and the
> > regmap_update_bits() call. Could you look into
> > just using regmap MMIO in that case?
> >
> > If you need examples, look at gpio-mvebu.c that calls
> > devm_regmap_init_mmio() for example.
> >
>
> That's really cool. Sorry, for not checking that earlier.
> I am pretty new to this.
>
> >> +static int sifive_direction_input(struct gpio_chip *gc, unsigned int
> >> offset)
> >> +static int sifive_direction_output(struct gpio_chip *gc, unsigned int
> >> offset,
> >> +static int sifive_get_direction(struct gpio_chip *gc, unsigned int offset)
> >> +static int sifive_get_value(struct gpio_chip *gc, unsigned int offset)
> >> +static void sifive_set_value(struct gpio_chip *gc, unsigned int offset,
> >
> > These functions look like a typical hardware that can use
> >
> > GPIOLIB_GENERIC and bgpio_init() to set up the accessors.
> >
> > See gpio-ftgpio010.c for an example.
> >
> > As a bonus you will get .get/.set_multiple implemented by
> > the generic GPIO.
> >
>
> Great. This will reduce the driver a code by a big factor.
> Thanks for the pointer.
>
>
> >> +static void sifive_irq_enable(struct irq_data *d)
> >> +static void sifive_irq_disable(struct irq_data *d)
> > (...)
> >> +static struct irq_chip sifive_irqchip = {
> >> + .name = "sifive-gpio",
> >> + .irq_set_type = sifive_irq_set_type,
> >> + .irq_mask = sifive_irq_mask,
> >> + .irq_unmask = sifive_irq_unmask,
> >> + .irq_enable = sifive_irq_enable,
> >> + .irq_disable= sifive_irq_disable,
> >
> > The handling of .irq_enable and .irq_disable has
> > changed upstream. Please align with the new codebase
> > as changed by Hans Verkuil:
> >
> > commit 461c1a7d4733d1dfd5c47b040cf32a5e7eefbc6c
> > "gpiolib: override irq_enable/disable"
> > commit 4e9439ddacea06f35acce4d374bf6bd0acf99bc8
> > "gpiolib: add flag to indicate if the irq is disabled"
> >
> > You will need to rebase your work on the v4.20-rc1 once it is
> > out. Right now the changes are on linux-next or my devel
> > branch.
>
> Will do.
>
> >
> >> + ngpio = of_irq_count(node);
> >> + if (ngpio >= MAX_GPIO) {
> >> + dev_err(dev, "Too many GPIO interrupts (max=%d)\n",
> >> MAX_GPIO);
> >> + return -ENXIO;
> >> + }
> > (...)
> >> + for (gpio = 0; gpio < ngpio; ++gpio) {
> >> + irq = platform_get_irq(pdev, gpio);
> >> + if (irq < 0) {
> >> + dev_err(dev, "invalid IRQ\n");
> >> + gpiochip_remove(&chip->gc);
> >> + return -ENODEV;
> >> + }
> >
> > This is an hierarchical IRQ so it should use an hierarchical
> > irqdomain.
> >
> > I am discussing with Thierry to make more generic irq domains
> > for hierarchical IRQ GPIOs, until then you have to loo
Re: [PATCH] z3fold: fix memory leak in kmem cache
On 9/17/19 5:53 PM, Vitaly Wool wrote:
> Currently there is a leak in init_z3fold_page() -- it allocates
> handles from kmem cache even for headless pages, but then they are
> never used and never freed, so eventually kmem cache may get
> exhausted. This patch provides a fix for that.
>
> Reported-by: Markus Linnala
> Signed-off-by: Vitaly Wool
Can a Fixes: commit be pinpointed, and CC stable added?
> ---
> mm/z3fold.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 6397725b5ec6..7dffef2599c3 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -301,14 +301,11 @@ static void z3fold_unregister_migration(struct
> z3fold_pool *pool)
> }
>
> /* Initializes the z3fold header of a newly allocated z3fold page */
> -static struct z3fold_header *init_z3fold_page(struct page *page,
> +static struct z3fold_header *init_z3fold_page(struct page *page, bool
> headless,
> struct z3fold_pool *pool, gfp_t gfp)
> {
> struct z3fold_header *zhdr = page_address(page);
> - struct z3fold_buddy_slots *slots = alloc_slots(pool, gfp);
> -
> - if (!slots)
> - return NULL;
> + struct z3fold_buddy_slots *slots;
>
> INIT_LIST_HEAD(&page->lru);
> clear_bit(PAGE_HEADLESS, &page->private);
> @@ -316,6 +313,12 @@ static struct z3fold_header *init_z3fold_page(struct
> page *page,
> clear_bit(NEEDS_COMPACTING, &page->private);
> clear_bit(PAGE_STALE, &page->private);
> clear_bit(PAGE_CLAIMED, &page->private);
> + if (headless)
> + return zhdr;
> +
> + slots = alloc_slots(pool, gfp);
> + if (!slots)
> + return NULL;
>
> spin_lock_init(&zhdr->page_lock);
> kref_init(&zhdr->refcount);
> @@ -962,7 +965,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t
> size, gfp_t gfp,
> if (!page)
> return -ENOMEM;
>
> - zhdr = init_z3fold_page(page, pool, gfp);
> + zhdr = init_z3fold_page(page, bud == HEADLESS, pool, gfp);
> if (!zhdr) {
> __free_page(page);
> return -ENOMEM;
>
Re: [PATCH v5] gpio/mpc8xxx: change irq handler from chained to normal
pon., 16 wrz 2019 o 08:08 Hui Song napisał(a):
>
> From: Song Hui
>
> More than one gpio controllers can share one interrupt, change the
> driver to request shared irq.
>
> Signed-off-by: Laurentiu Tudor
> Signed-off-by: Alex Marginean
> Signed-off-by: Song Hui
> ---
> Changes in v5:
> - add traverse every bit function.
> Changes in v4:
> - convert 'pr_err' to 'dev_err'.
> Changes in v3:
> - update the patch description.
> Changes in v2:
> - delete the compatible of ls1088a.
> drivers/gpio/gpio-mpc8xxx.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 16a47de..3a06ca9 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #define MPC8XXX_GPIO_PINS 32
>
> @@ -127,20 +128,20 @@ static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc,
> unsigned offset)
> return -ENXIO;
> }
>
> -static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
> +static irqreturn_t mpc8xxx_gpio_irq_cascade(int irq, void *data)
> {
> - struct mpc8xxx_gpio_chip *mpc8xxx_gc =
> irq_desc_get_handler_data(desc);
> - struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = (struct mpc8xxx_gpio_chip
> *)data;
There's no need to cast void pointers.
> struct gpio_chip *gc = &mpc8xxx_gc->gc;
> unsigned int mask;
> + int i;
>
> mask = gc->read_reg(mpc8xxx_gc->regs + GPIO_IER)
> & gc->read_reg(mpc8xxx_gc->regs + GPIO_IMR);
> - if (mask)
> + for_each_set_bit(i, &mask, 32)
> generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
> -32 - ffs(mask)));
> - if (chip->irq_eoi)
> - chip->irq_eoi(&desc->irq_data);
> +31 - i));
> +
> + return IRQ_HANDLED;
> }
>
> static void mpc8xxx_irq_unmask(struct irq_data *d)
> @@ -388,8 +389,8 @@ static int mpc8xxx_probe(struct platform_device *pdev)
>
> ret = gpiochip_add_data(gc, mpc8xxx_gc);
> if (ret) {
> - pr_err("%pOF: GPIO chip registration failed with status %d\n",
> - np, ret);
> + dev_err(&pdev->dev, "%pOF: GPIO chip registration failed with
> status %d\n",
> + np, ret);
> goto err;
> }
>
> @@ -409,8 +410,15 @@ static int mpc8xxx_probe(struct platform_device *pdev)
> if (devtype->gpio_dir_in_init)
> devtype->gpio_dir_in_init(gc);
>
> - irq_set_chained_handler_and_data(mpc8xxx_gc->irqn,
> -mpc8xxx_gpio_irq_cascade,
> mpc8xxx_gc);
> + ret = request_irq(mpc8xxx_gc->irqn, mpc8xxx_gpio_irq_cascade,
> + IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade",
> + mpc8xxx_gc);
You never free this irq. Maybe use devm_request_irq()?
Bart
> + if (ret) {
> + dev_err(&pdev->dev, "%s: failed to request_irq(%d), ret =
> %d\n",
> + np->full_name, mpc8xxx_gc->irqn, ret);
> + goto err;
> + }
> +
> return 0;
> err:
> iounmap(mpc8xxx_gc->regs);
> --
> 2.9.5
>
Re: printk meeting at LPC
On 2019-09-18, Sergey Senozhatsky wrote:
>> For instance, tty/sysrq must be able to switch printk emergency
>> on/off.
>
> How did we come up to that _sync() printk() emergency mode (when we
> make sure that there is no active printing kthread)? We had a number
> of cases (complaints) of lost kernel messages. There are scenarios in
> which we cannot offload to async preemptible printing kthread, because
> current control path is, for instance, going to reboot the kernel. In
> sync printk() mode we have some sort (!) of guarantees that when we do
>
> pr_emerg("Restarting system\n");
> kmsg_dump(KMSG_DUMP_RESTART);
> machine_restart(cmd);
>
> pr_emerg("Restarting system\n") is going to flush logbuf before the
> system will machine_restart().
Yes, this was why I asked Daniel how the bsod stuff will be
implemented. We don't want a bsod just because we are
restarting. Perhaps write_atomic() should also have a "reason" argument
like kmsg_dump does. I will keep in touch with Daniel to make sure we
are sync on this.
> It's going to be a bit harder when we have per-console kthread.
Each console has its own iterator. This iterators will need to advance,
regardless if the message was printed via write() or write_atomic().
John Ogness
Running AF_XDP inside Docker using veth driver
Hello, I wrote a test case handling network traffic in user-space inside a Docker network by using an XDP socket with libbpf. You can find the code in https://github.com/glasnostic/af_xdp_test My kernel version is 5.1 with XDP_SOCK enabled. In this example, I have an unstable result while getting packets from the XDP socket. We can see a significant delay (~10s) until the packets are received by the process. It seems that XDP processes packets in batches and only when enough packets exist, all of the packets are sent to the userspace process. This is a problem for traffic consisting of one packet (e.g. ARP, PING). What is the correct way to deal with this problem? E.g. can we force XDP to flush packets? Thanks for the help. - Yu-Han
Re: [PATCH] arch/microblaze: support get_user() of size 8 bytes
On 17. 09. 19 3:39, Randy Dunlap wrote:
> From: Randy Dunlap
>
> arch/microblaze/ is missing support for get_user() of size 8 bytes,
> so add it by using __copy_from_user().
>
> While there, also drop a lot of the code duplication.
>
> Fixes these build errors:
>drivers/infiniband/core/uverbs_main.o: In function `ib_uverbs_write':
>drivers/infiniband/core/.tmp_gl_uverbs_main.o:(.text+0x13a4): undefined
> reference to `__user_bad'
>drivers/android/binder.o: In function `binder_thread_write':
>drivers/android/.tmp_gl_binder.o:(.text+0xda6c): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xda98): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xdf10): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xe498): undefined reference to
> `__user_bad'
>drivers/android/binder.o:drivers/android/.tmp_gl_binder.o:(.text+0xea78):
> more undefined references to `__user_bad' follow
>
> 'make allmodconfig' now builds successfully for arch/microblaze/.
>
> Fixes: 538722ca3b76 ("microblaze: fix get_user/put_user side-effects")
> Reported-by: kbuild test robot
> Signed-off-by: Randy Dunlap
> Acked-by: Linus Torvalds
> Cc: Al Viro
> Cc: Steven J. Magnani
> Cc: Michal Simek
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Andrew Morton
> Cc: Doug Ledford
> ---
> v4: drop code duplication (Linus).
>
>
> arch/microblaze/include/asm/uaccess.h | 42 +---
> 1 file changed, 9 insertions(+), 33 deletions(-)
>
> --- lnx-53.orig/arch/microblaze/include/asm/uaccess.h
> +++ lnx-53/arch/microblaze/include/asm/uaccess.h
> @@ -163,44 +163,15 @@ extern long __user_bad(void);
> * Returns zero on success, or -EFAULT on error.
> * On error, the variable @x is set to zero.
> */
> -#define get_user(x, ptr) \
> - __get_user_check((x), (ptr), sizeof(*(ptr)))
> -
> -#define __get_user_check(x, ptr, size)
> \
> -({ \
> - unsigned long __gu_val = 0; \
> - const typeof(*(ptr)) __user *__gu_addr = (ptr); \
> - int __gu_err = 0; \
> - \
> - if (access_ok(__gu_addr, size)) { \
> - switch (size) { \
> - case 1: \
> - __get_user_asm("lbu", __gu_addr, __gu_val, \
> -__gu_err); \
> - break; \
> - case 2: \
> - __get_user_asm("lhu", __gu_addr, __gu_val, \
> -__gu_err); \
> - break; \
> - case 4: \
> - __get_user_asm("lw", __gu_addr, __gu_val, \
> -__gu_err); \
> - break; \
> - default:\
> - __gu_err = __user_bad();\
> - break; \
> - } \
> - } else {\
> - __gu_err = -EFAULT; \
> - } \
> - x = (__force typeof(*(ptr)))__gu_val; \
> - __gu_err; \
> +#define get_user(x, ptr) ({ \
> + const typeof(*(ptr)) __user *__gu_ptr = (ptr); \
> + access_ok(__gu_ptr, sizeof(*__gu_ptr)) ?\
> + __get_user(x, __gu_ptr) : -EFAULT; \
> })
>
> #define __get_user(x, ptr) \
> ({ \
> unsigned long __gu_val = 0; \
> - /*unsigned long __gu_ptr = (unsigned long)(ptr);*/ \
> long __gu_err; \
> switch (sizeof(*(ptr))) { \
> case 1: \
> @@ -212,6 +183,11 @@ extern long __user_bad(void);
> case 4:
Re: Regression in dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") [Was: Regression in fd5f7cde1b85 ("...")]
On (09/18/19 09:11), Uwe Kleine-König wrote:
> I rechecked and indeed fd5f7cde1b85's parent has the problem, too, so I
> did a mistake during my bisection :-|
>
> Redoing the bisection (a bit quicker this time) points to
>
> dbdda842fe96 ("printk: Add console owner and waiter logic to load balance
> console writes")
>
> Sorry for the confusion.
No worries!
[..]
> > So I'd say that lockdep is correct, but there are several hacks which
> > prevent actual deadlock.
>
> Just to make sure, I got you right: With the way lockdep works it is
> right to assume there is a problem, but in fact there isn't?
I'd probably say so... Unless I'm missing something.
sysrq-over-serial is handled from the serial driver's IRQ handler,
under serial driver's port->lock. sysrq handling calls printk(), which
takes console_sem/owner and re-enters the serial driver via ->write()
callback.
So lockdep sees a reverse locking pattern: port->lock goes before
console_sem/owner, which is not the usual order.
> This is IMHO unfortunate because such false positives reduces the
> usefulness of lockdep considerably. :-|
I agree.
port->sysrq state is global to uart port. IOW, if CPUA sets port->sysrq
then all printk->write() paths (from any other CPU) become lockless.
This makes me wonder is we really need to hold port->lock for
uart_handle_sysrq_char(). I sort of doubt it...
Can you try the following patch? It's against linux-next, I guess
you can backport to your kernel.
The basic idea is to handle sysrq out of port->lock.
I didn't test it all (not even sure if it compiles).
---
drivers/tty/serial/imx.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 87c58f9f6390..f0dd807b52df 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -731,9 +731,9 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
struct imx_port *sport = dev_id;
unsigned int rx, flg, ignored = 0;
struct tty_port *port = &sport->port.state->port;
+ unsigned long flags;
- spin_lock(&sport->port.lock);
-
+ uart_port_lock_irqsave(&sport->port, flags);
while (imx_uart_readl(sport, USR2) & USR2_RDR) {
u32 usr2;
@@ -749,8 +749,8 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
continue;
}
- if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
- continue;
+ if (uart_prepare_sysrq_char(&sport->port, (unsigned char)rx))
+ break;
if (unlikely(rx & URXD_ERR)) {
if (rx & URXD_BRK)
@@ -792,7 +792,7 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
}
out:
- spin_unlock(&sport->port.lock);
+ uart_unlock_and_check_sysrq(&sport->port, flags);
tty_flip_buffer_push(port);
return IRQ_HANDLED;
}
[PATCH v2 1/7] counter: Simplify the count_read and count_write callbacks
The count_read and count_write callbacks are simplified to pass val as
unsigned long rather than as an opaque data structure. The opaque
counter_count_read_value and counter_count_write_value structures,
counter_count_value_type enum, and relevant counter_count_read_value_set
and counter_count_write_value_get functions, are removed as they are no
longer used.
Signed-off-by: William Breathitt Gray
---
drivers/counter/counter.c | 66 +--
include/linux/counter.h | 43 +++--
2 files changed, 12 insertions(+), 97 deletions(-)
diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
index 106bc7180cd8..1d08f1437b1b 100644
--- a/drivers/counter/counter.c
+++ b/drivers/counter/counter.c
@@ -246,60 +246,6 @@ void counter_signal_read_value_set(struct
counter_signal_read_value *const val,
}
EXPORT_SYMBOL_GPL(counter_signal_read_value_set);
-/**
- * counter_count_read_value_set - set counter_count_read_value data
- * @val: counter_count_read_value structure to set
- * @type: property Count data represents
- * @data: Count data
- *
- * This function sets an opaque counter_count_read_value structure with the
- * provided Count data.
- */
-void counter_count_read_value_set(struct counter_count_read_value *const val,
- const enum counter_count_value_type type,
- void *const data)
-{
- switch (type) {
- case COUNTER_COUNT_POSITION:
- val->len = sprintf(val->buf, "%lu\n", *(unsigned long *)data);
- break;
- default:
- val->len = 0;
- }
-}
-EXPORT_SYMBOL_GPL(counter_count_read_value_set);
-
-/**
- * counter_count_write_value_get - get counter_count_write_value data
- * @data: Count data
- * @type: property Count data represents
- * @val: counter_count_write_value structure containing data
- *
- * This function extracts Count data from the provided opaque
- * counter_count_write_value structure and stores it at the address provided by
- * @data.
- *
- * RETURNS:
- * 0 on success, negative error number on failure.
- */
-int counter_count_write_value_get(void *const data,
- const enum counter_count_value_type type,
- const struct counter_count_write_value *const
val)
-{
- int err;
-
- switch (type) {
- case COUNTER_COUNT_POSITION:
- err = kstrtoul(val->buf, 0, data);
- if (err)
- return err;
- break;
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(counter_count_write_value_get);
-
struct counter_attr_parm {
struct counter_device_attr_group *group;
const char *prefix;
@@ -788,13 +734,13 @@ static ssize_t counter_count_show(struct device *dev,
const struct counter_count_unit *const component = devattr->component;
struct counter_count *const count = component->count;
int err;
- struct counter_count_read_value val = { .buf = buf };
+ unsigned long val;
err = counter->ops->count_read(counter, count, &val);
if (err)
return err;
- return val.len;
+ return sprintf(buf, "%lu\n", val);
}
static ssize_t counter_count_store(struct device *dev,
@@ -806,9 +752,13 @@ static ssize_t counter_count_store(struct device *dev,
const struct counter_count_unit *const component = devattr->component;
struct counter_count *const count = component->count;
int err;
- struct counter_count_write_value val = { .buf = buf };
+ unsigned long val;
+
+ err = kstrtoul(buf, 0, &val);
+ if (err)
+ return err;
- err = counter->ops->count_write(counter, count, &val);
+ err = counter->ops->count_write(counter, count, val);
if (err)
return err;
diff --git a/include/linux/counter.h b/include/linux/counter.h
index a061cdcdef7c..7e40796598a6 100644
--- a/include/linux/counter.h
+++ b/include/linux/counter.h
@@ -300,24 +300,6 @@ struct counter_signal_read_value {
size_t len;
};
-/**
- * struct counter_count_read_value - Opaque Count read value
- * @buf: string representation of Count read value
- * @len: length of string in @buf
- */
-struct counter_count_read_value {
- char *buf;
- size_t len;
-};
-
-/**
- * struct counter_count_write_value - Opaque Count write value
- * @buf: string representation of Count write value
- */
-struct counter_count_write_value {
- const char *buf;
-};
-
/**
* struct counter_ops - Callbacks from driver
* @signal_read: optional read callback for Signal attribute. The read
@@ -328,15 +310,10 @@ struct counter_count_write_value {
* signal_read callback.
* @count_read:optional read callback for Count attribute. The
read
* value of the respect
[PATCH v2 2/7] counter: Simplify the signal_read callback
The signal_read callback is simplified to pass val as a
counter_signal_val enum rather than as an opaque data structure. The
opaque counter_signal_read_value structure and relevant
counter_signal_read_value_set function are removed as they are no longer
used. In addition, the counter_signal_level enum is replaced by the
similar counter_signal_value enum.
Signed-off-by: William Breathitt Gray
---
drivers/counter/counter.c | 35 +++
include/linux/counter.h | 31 +--
2 files changed, 12 insertions(+), 54 deletions(-)
diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
index 1d08f1437b1b..6a683d086008 100644
--- a/drivers/counter/counter.c
+++ b/drivers/counter/counter.c
@@ -220,32 +220,6 @@ ssize_t counter_device_enum_available_read(struct
counter_device *counter,
}
EXPORT_SYMBOL_GPL(counter_device_enum_available_read);
-static const char *const counter_signal_level_str[] = {
- [COUNTER_SIGNAL_LEVEL_LOW] = "low",
- [COUNTER_SIGNAL_LEVEL_HIGH] = "high"
-};
-
-/**
- * counter_signal_read_value_set - set counter_signal_read_value data
- * @val: counter_signal_read_value structure to set
- * @type: property Signal data represents
- * @data: Signal data
- *
- * This function sets an opaque counter_signal_read_value structure with the
- * provided Signal data.
- */
-void counter_signal_read_value_set(struct counter_signal_read_value *const val,
- const enum counter_signal_value_type type,
- void *const data)
-{
- if (type == COUNTER_SIGNAL_LEVEL)
- val->len = sprintf(val->buf, "%s\n",
- counter_signal_level_str[*(enum
counter_signal_level *)data]);
- else
- val->len = 0;
-}
-EXPORT_SYMBOL_GPL(counter_signal_read_value_set);
-
struct counter_attr_parm {
struct counter_device_attr_group *group;
const char *prefix;
@@ -315,6 +289,11 @@ struct counter_signal_unit {
struct counter_signal *signal;
};
+static const char *const counter_signal_value_str[] = {
+ [COUNTER_SIGNAL_LOW] = "low",
+ [COUNTER_SIGNAL_HIGH] = "high"
+};
+
static ssize_t counter_signal_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -323,13 +302,13 @@ static ssize_t counter_signal_show(struct device *dev,
const struct counter_signal_unit *const component = devattr->component;
struct counter_signal *const signal = component->signal;
int err;
- struct counter_signal_read_value val = { .buf = buf };
+ enum counter_signal_value val;
err = counter->ops->signal_read(counter, signal, &val);
if (err)
return err;
- return val.len;
+ return sprintf(buf, "%s\n", counter_signal_value_str[val]);
}
struct counter_name_unit {
diff --git a/include/linux/counter.h b/include/linux/counter.h
index 7e40796598a6..32fb4d8cc3fd 100644
--- a/include/linux/counter.h
+++ b/include/linux/counter.h
@@ -290,24 +290,16 @@ struct counter_device_state {
const struct attribute_group **groups;
};
-/**
- * struct counter_signal_read_value - Opaque Signal read value
- * @buf: string representation of Signal read value
- * @len: length of string in @buf
- */
-struct counter_signal_read_value {
- char *buf;
- size_t len;
+enum counter_signal_value {
+ COUNTER_SIGNAL_LOW = 0,
+ COUNTER_SIGNAL_HIGH
};
/**
* struct counter_ops - Callbacks from driver
* @signal_read: optional read callback for Signal attribute. The read
* value of the respective Signal should be passed back via
- * the val parameter. val points to an opaque type which
- * should be set only by calling the
- * counter_signal_read_value_set function from within the
- * signal_read callback.
+ * the val parameter.
* @count_read:optional read callback for Count attribute. The
read
* value of the respective Count should be passed back via
* the val parameter.
@@ -332,7 +324,7 @@ struct counter_signal_read_value {
struct counter_ops {
int (*signal_read)(struct counter_device *counter,
struct counter_signal *signal,
- struct counter_signal_read_value *val);
+ enum counter_signal_value *val);
int (*count_read)(struct counter_device *counter,
struct counter_count *count, unsigned long *val);
int (*count_write)(struct counter_device *counter,
@@ -452,19 +444,6 @@ struct counter_device {
void *priv;
};
-enum counter_signal_level {
- COUNTER_SIGNAL_LEVEL_LOW = 0,
- COUNTER_SIGNAL_LEVEL_HIGH
-};
-
-enum counter_sig
[PATCH v2 0/7] counter: Simplify count_read/count_write/signal_read
Changes in v2: - Update the rest of the drivers under drivers/counter The changes in this patchset will not affect the userspace interface. Rather, these changes are intended to simplify the kernelspace Counter callbacks for counter device driver authors. The following main changes are proposed: * Retire the opaque counter_count_read_value/counter_count_write_value structures and simply represent count data as an unsigned integer. * Retire the opaque counter_signal_read_value structure and represent Signal data as a counter_signal_value enum. These changes should reduce some complexity and code in the use and implementation of the count_read, count_write, and signal_read callbacks. The opaque structures for Count data and Signal data were introduced originally in anticipation of supporting various representations of counter data (e.g. arbitrary-precision tallies, floating-point spherical coordinate positions, etc). However, with the counter device drivers that have appeared, it's become apparent that utilizing opaque structures in kernelspace is not the best approach to take. I believe it is best to let userspace applications decide how to interpret the count data they receive. There are a couple of reasons why it would be good to do so: * Users use their devices in unexpected ways. For example, a quadrature encoder counter device is typically used to keep track of the position of a motor, but a user could set the device in a pulse-direction mode and instead use it to count sporadic rising edges from an arbitrary signal line unrelated to positioning. Users should have the freedom to decide what their data represents. * Most counter devices represent data as unsigned integers anyway. For example, whether the device is a tally counter or position counter, the count data is represented to the user as an unsigned integer value. So specifying that one device is representing tallies while the other specifies positions does not provide much utility from an interface perspective. For these reasons, the count_read and count_write callbacks have been redefined to pass count data directly as unsigned long instead of passed via opaque structures: count_read(struct counter_device *counter, struct counter_count *count, unsigned long *val); count_write(struct counter_device *counter, struct counter_count *count, unsigned long val); Similarly, the signal_read is redefined to pass Signal data directly as a counter_signal_value enum instead of via an opaque structure: signal_read(struct counter_device *counter, struct counter_signal *signal, enum counter_signal_value *val); The counter_signal_value enum is simply the counter_signal_level enum redefined to remove the references to the Signal data "level" data type. William Breathitt Gray (7): counter: Simplify the count_read and count_write callbacks counter: Simplify the signal_read callback docs: driver-api: generic-counter: Update Count and Signal data types counter: 104-quad-8: Update count_read/count_write/signal_read callbacks counter: ftm-quaddec: Update count_read and count_write callbacks counter: stm32-lptimer-cnt: Update count_read callback counter: stm32-timer-cnt: Update count_read and count_write callbacks Documentation/driver-api/generic-counter.rst | 22 ++-- drivers/counter/104-quad-8.c | 33 ++ drivers/counter/counter.c| 101 +++ drivers/counter/ftm-quaddec.c| 14 +-- drivers/counter/stm32-lptimer-cnt.c | 5 +- drivers/counter/stm32-timer-cnt.c| 17 +--- include/linux/counter.h | 74 ++ 7 files changed, 53 insertions(+), 213 deletions(-) -- 2.23.0
[PATCH v2 3/7] docs: driver-api: generic-counter: Update Count and Signal data types
Count data is now always represented as an unsigned integer, while Signal data is either SIGNAL_LOW or SIGNAL_HIGH. Signed-off-by: William Breathitt Gray --- Documentation/driver-api/generic-counter.rst | 22 +++- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index 8382f01a53e3..161652fc1025 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -39,10 +39,7 @@ There are three core components to a counter: COUNT - A Count represents the count data for a set of Signals. The Generic -Counter interface provides the following available count data types: - -* COUNT_POSITION: - Unsigned integer value representing position. +Counter interface represents the count data as an unsigned integer. A Count has a count function mode which represents the update behavior for the count data. The Generic Counter interface provides the following @@ -93,19 +90,16 @@ SIGNAL A Signal represents a counter input data; this is the input data that is evaluated by the counter to determine the count data; e.g. a quadrature signal output line of a rotary encoder. Not all counter devices provide -user access to the Signal data. - -The Generic Counter interface provides the following available signal -data types for when the Signal data is available for user access: +user access to the Signal data, so exposure is optional for drivers. -* SIGNAL_LEVEL: - Signal line state level. The following states are possible: +When the Signal data is available for user access, the Generic Counter +interface provides the following available signal values: - - SIGNAL_LEVEL_LOW: -Signal line is in a low state. +* SIGNAL_LOW: + Signal line is in a low state. - - SIGNAL_LEVEL_HIGH: -Signal line is in a high state. +* SIGNAL_HIGH: + Signal line is in a high state. A Signal may be associated with one or more Counts. -- 2.23.0
[PATCH v2 4/7] counter: 104-quad-8: Update count_read/count_write/signal_read callbacks
The count_read and count_write callbacks pass unsigned long now, while
the signal_read callback passes an enum counter_signal_value.
Signed-off-by: William Breathitt Gray
---
drivers/counter/104-quad-8.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
index 00b113f4b958..17e67a84777d 100644
--- a/drivers/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -562,11 +562,10 @@ static const struct iio_chan_spec quad8_channels[] = {
};
static int quad8_signal_read(struct counter_device *counter,
- struct counter_signal *signal, struct counter_signal_read_value *val)
+ struct counter_signal *signal, enum counter_signal_value *val)
{
const struct quad8_iio *const priv = counter->priv;
unsigned int state;
- enum counter_signal_level level;
/* Only Index signal levels can be read */
if (signal->id < 16)
@@ -575,22 +574,19 @@ static int quad8_signal_read(struct counter_device
*counter,
state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
& BIT(signal->id - 16);
- level = (state) ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
-
- counter_signal_read_value_set(val, COUNTER_SIGNAL_LEVEL, &level);
+ *val = (state) ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
return 0;
}
static int quad8_count_read(struct counter_device *counter,
- struct counter_count *count, struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
unsigned int flags;
unsigned int borrow;
unsigned int carry;
- unsigned long position;
int i;
flags = inb(base_offset + 1);
@@ -598,36 +594,27 @@ static int quad8_count_read(struct counter_device
*counter,
carry = !!(flags & QUAD8_FLAG_CT);
/* Borrow XOR Carry effectively doubles count range */
- position = (unsigned long)(borrow ^ carry) << 24;
+ *val = (unsigned long)(borrow ^ carry) << 24;
/* Reset Byte Pointer; transfer Counter to Output Latch */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
base_offset + 1);
for (i = 0; i < 3; i++)
- position |= (unsigned long)inb(base_offset) << (8 * i);
-
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &position);
+ *val |= (unsigned long)inb(base_offset) << (8 * i);
return 0;
}
static int quad8_count_write(struct counter_device *counter,
- struct counter_count *count, struct counter_count_write_value *val)
+ struct counter_count *count, unsigned long val)
{
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
- int err;
- unsigned long position;
int i;
- err = counter_count_write_value_get(&position, COUNTER_COUNT_POSITION,
- val);
- if (err)
- return err;
-
/* Only 24-bit values are supported */
- if (position > 0xFF)
+ if (val > 0xFF)
return -EINVAL;
/* Reset Byte Pointer */
@@ -635,7 +622,7 @@ static int quad8_count_write(struct counter_device *counter,
/* Counter can only be set via Preset Register */
for (i = 0; i < 3; i++)
- outb(position >> (8 * i), base_offset);
+ outb(val >> (8 * i), base_offset);
/* Transfer Preset Register to Counter */
outb(QUAD8_CTR_RLD | QUAD8_RLD_PRESET_CNTR, base_offset + 1);
@@ -644,9 +631,9 @@ static int quad8_count_write(struct counter_device *counter,
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
/* Set Preset Register back to original value */
- position = priv->preset[count->id];
+ val = priv->preset[count->id];
for (i = 0; i < 3; i++)
- outb(position >> (8 * i), base_offset);
+ outb(val >> (8 * i), base_offset);
/* Reset Borrow, Carry, Compare, and Sign flags */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_FLAGS, base_offset + 1);
--
2.23.0
[PATCH v2 5/7] counter: ftm-quaddec: Update count_read and count_write callbacks
The count_read and count_write callbacks pass unsigned long now.
Cc: Patrick Havelange
Signed-off-by: William Breathitt Gray
---
drivers/counter/ftm-quaddec.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
index 4046aa9f9234..c2b3fdfd8b77 100644
--- a/drivers/counter/ftm-quaddec.c
+++ b/drivers/counter/ftm-quaddec.c
@@ -178,31 +178,25 @@ static const enum counter_count_function
ftm_quaddec_count_functions[] = {
static int ftm_quaddec_count_read(struct counter_device *counter,
struct counter_count *count,
- struct counter_count_read_value *val)
+ unsigned long *val)
{
struct ftm_quaddec *const ftm = counter->priv;
uint32_t cntval;
ftm_read(ftm, FTM_CNT, &cntval);
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cntval);
+ *val = cntval;
return 0;
}
static int ftm_quaddec_count_write(struct counter_device *counter,
struct counter_count *count,
- struct counter_count_write_value *val)
+ const unsigned long val)
{
struct ftm_quaddec *const ftm = counter->priv;
- u32 cnt;
- int err;
- err = counter_count_write_value_get(&cnt, COUNTER_COUNT_POSITION, val);
- if (err)
- return err;
-
- if (cnt != 0) {
+ if (val != 0) {
dev_warn(&ftm->pdev->dev, "Can only accept '0' as new counter
value\n");
return -EINVAL;
}
--
2.23.0
[PATCH v2 6/7] counter: stm32-lptimer-cnt: Update count_read callback
The count_read callback passes unsigned long now.
Cc: Fabrice Gasnier
Signed-off-by: William Breathitt Gray
---
drivers/counter/stm32-lptimer-cnt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/counter/stm32-lptimer-cnt.c
b/drivers/counter/stm32-lptimer-cnt.c
index bbc930a5962c..73bb773f5e6d 100644
--- a/drivers/counter/stm32-lptimer-cnt.c
+++ b/drivers/counter/stm32-lptimer-cnt.c
@@ -377,8 +377,7 @@ static enum counter_synapse_action
stm32_lptim_cnt_synapse_actions[] = {
};
static int stm32_lptim_cnt_read(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
struct stm32_lptim_cnt *const priv = counter->priv;
u32 cnt;
@@ -388,7 +387,7 @@ static int stm32_lptim_cnt_read(struct counter_device
*counter,
if (ret)
return ret;
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cnt);
+ *val = cnt;
return 0;
}
--
2.23.0
[PATCH v2 7/7] counter: stm32-timer-cnt: Update count_read and count_write callbacks
The count_read and count_write callbacks pass unsigned long now.
Cc: Fabrice Gasnier
Signed-off-by: William Breathitt Gray
---
drivers/counter/stm32-timer-cnt.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/counter/stm32-timer-cnt.c
b/drivers/counter/stm32-timer-cnt.c
index 644ba18a72ad..839083543323 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -48,34 +48,27 @@ static enum counter_count_function stm32_count_functions[]
= {
};
static int stm32_count_read(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
struct stm32_timer_cnt *const priv = counter->priv;
u32 cnt;
regmap_read(priv->regmap, TIM_CNT, &cnt);
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cnt);
+ *val = cnt;
return 0;
}
static int stm32_count_write(struct counter_device *counter,
struct counter_count *count,
-struct counter_count_write_value *val)
+const unsigned long val)
{
struct stm32_timer_cnt *const priv = counter->priv;
- u32 cnt;
- int err;
-
- err = counter_count_write_value_get(&cnt, COUNTER_COUNT_POSITION, val);
- if (err)
- return err;
- if (cnt > priv->ceiling)
+ if (val > priv->ceiling)
return -EINVAL;
- return regmap_write(priv->regmap, TIM_CNT, cnt);
+ return regmap_write(priv->regmap, TIM_CNT, val);
}
static int stm32_count_function_get(struct counter_device *counter,
--
2.23.0
Re: [PATCH] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
On 2019-09-18 08:38, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> Before commit e42ee61017f5 ("of: Let of_for_each_phandle fallback to
> non-negative cell_count") the iterator functions calling
> of_for_each_phandle assumed a cell count of 0 if cells_name was NULL.
> This corner case was missed when implementing the fallback logic in
> e42ee61017f5 and resulted in an endless loop.
>
> Restore the old behaviour of of_count_phandle_with_args() and
> of_parse_phandle_with_args() and add a check to
> of_phandle_iterator_init() to prevent a similar failure as a safety
> precaution. of_parse_phandle_with_args_map() doesn't need a similar fix
> as cells_name isn't NULL there.
>
> Affected drivers are:
> - drivers/base/power/domain.c
> - drivers/base/power/domain.c
> - drivers/clk/ti/clk-dra7-atl.c
> - drivers/hwmon/ibmpowernv.c
> - drivers/i2c/muxes/i2c-demux-pinctrl.c
> - drivers/iommu/mtk_iommu.c
> - drivers/net/ethernet/freescale/fman/mac.c
> - drivers/opp/of.c
> - drivers/perf/arm_dsu_pmu.c
> - drivers/regulator/of_regulator.c
> - drivers/remoteproc/imx_rproc.c
> - drivers/soc/rockchip/pm_domains.c
> - sound/soc/fsl/imx-audmix.c
> - sound/soc/fsl/imx-audmix.c
> - sound/soc/meson/axg-card.c
> - sound/soc/samsung/tm2_wm5110.c
> - sound/soc/samsung/tm2_wm5110.c
>
> Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for
> helping pinpoint the actual problem and the testers for confirming this
> fix.
>
> Fixes: e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative
> cell_count")
> Tested-by: Marek Szyprowski
> Tested-by: Geert Uytterhoeven
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> compared to the untested patch I sent yesterday I also fixed
> of_parse_phandle_with_args which has three users that pass
> cells_name=NULL. (i.e. drivers/clk/ti/clk-dra7-atl.c,
> sound/soc/fsl/imx-audmix.c, sound/soc/samsung/tm2_wm5110.c) I didn't
> look closely, but maybe these could be converted to use of_parse_phandle
> as there are no arguments to be processed with no cells_name?!
>
> Best regards
> Uwe
>
> drivers/of/base.c | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 2f25d2dfecfa..25ee07c0a3cd 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1286,6 +1286,13 @@ int of_phandle_iterator_init(struct
> of_phandle_iterator *it,
>
> memset(it, 0, sizeof(*it));
>
> + /*
> + * one of cell_count or cells_name must be provided to determine the
> + * argument length.
> + */
> + if (cell_count < 0 && !cells_name)
> + return -EINVAL;
> +
> list = of_get_property(np, list_name, &size);
> if (!list)
> return -ENOENT;
> @@ -1512,10 +1519,17 @@ int of_parse_phandle_with_args(const struct
> device_node *np, const char *list_na
> const char *cells_name, int index,
> struct of_phandle_args *out_args)
> {
> + int cell_count = -1;
> +
> if (index < 0)
> return -EINVAL;
> - return __of_parse_phandle_with_args(np, list_name, cells_name, -1,
> - index, out_args);
> +
> + /* If cells_name if NULL we assume a cell count of 0 */
> + if (!cells_name)
> + cell_count = 0;
> +
> + return __of_parse_phandle_with_args(np, list_name, cells_name,
> + cell_count, index, out_args);
> }
> EXPORT_SYMBOL(of_parse_phandle_with_args);
>
> @@ -1765,6 +1779,18 @@ int of_count_phandle_with_args(const struct
> device_node *np, const char *list_na
> struct of_phandle_iterator it;
> int rc, cur_index = 0;
>
> + /* If cells_name is NULL we assume a cell count of 0 */
> + if (cells_name == NULL) {
A couple of nits.
I don't know if there are other considerations, but in the previous two
hunks you use !cells_name instead of comparing explicitly with NULL.
Personally, I find the shorter form more readable, and in the name of
consistency bla bla...
Also, the comment explaining this NULL-check didn't really make sense
to me until I realized that knowing the cell count to be zero makes
counting trivial. Something along those lines should perhaps be in the
comment?
But as I said, these are nits. Feel free to ignore.
Cheers,
Peter
> + const __be32 *list;
> + int size;
> +
> + list = of_get_property(np, list_name, &size);
> + if (!list)
> + return -ENOENT;
> +
> + return size / sizeof(*list);
> + }
> +
> rc = of_phandle_iterator_init(&it, np, list_name, cells_name, -1);
> if (rc)
> return rc;
>
Re: [RFC PATCH] memalloc_noio: update the comment to make it cleaner
On 2019/9/18 15:25, Michal Hocko wrote:
On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
From: Xiubo Li
The GFP_NOIO means all further allocations will implicitly drop
both __GFP_IO and __GFP_FS flags and so they are safe for both the
IO critical section and the the critical section from the allocation
recursion point of view. Not only the __GFP_IO, which a bit confusing
when reading the code or using the save/restore pair.
Historically GFP_NOIO has always implied GFP_NOFS as well. I can imagine
that this might come as an surprise for somebody not familiar with the
code though.
Yeah, it true.
I am wondering whether your update of the documentation
would be better off at __GFP_FS, __GFP_IO resp. GFP_NOFS, GFP_NOIO level.
This interface is simply a way to set a scoped NO{IO,FS} context.
The "Documentation/core-api/gfp_mask-from-fs-io.rst" is already very
detail about them all.
This fixing just means to make sure that it won't surprise someone who
is having a quickly through some code and not familiar much about the
detail. It may make not much sense ?
Thanks,
BRs
Xiubo
Signed-off-by: Xiubo Li
---
include/linux/sched/mm.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 4a7944078cc3..9bdc97e52de1 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -211,10 +211,11 @@ static inline void fs_reclaim_release(gfp_t gfp_mask) { }
* memalloc_noio_save - Marks implicit GFP_NOIO allocation scope.
*
* This functions marks the beginning of the GFP_NOIO allocation scope.
- * All further allocations will implicitly drop __GFP_IO flag and so
- * they are safe for the IO critical section from the allocation recursion
- * point of view. Use memalloc_noio_restore to end the scope with flags
- * returned by this function.
+ * All further allocations will implicitly drop __GFP_IO and __GFP_FS
+ * flags and so they are safe for both the IO critical section and the
+ * the critical section from the allocation recursion point of view. Use
+ * memalloc_noio_restore to end the scope with flags returned by this
+ * function.
*
* This function is safe to be used from any context.
*/
--
2.21.0
[PATCH v2 1/4] dt: spi: Add Renesas RZ/N1 binding documentation
From: Phil Edworthy The Renesas RZ/N1 SPI Controller is based on the Synopsys DW SSI, but has additional registers for software CS control and DMA. This patch does not address the changes required for DMA support, it simply adds the compatible string. The CS functionality is not very useful and also not needed as Linux can use gpios for the CS signals. Add a compatible string to handle any unforeseen issues that may arise, and pave the way for DMA support. Signed-off-by: Gareth Williams Signed-off-by: Phil Edworthy --- Note: All the other manufacturers detail their compatible strings in snps,dw-apb-ssi.txt. I think it makes sense for rzn1 to be in it's own file due to the changes made to the peripheral for DMA support. v2: - No changes. --- Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt diff --git a/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt b/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt new file mode 100644 index 000..fb1a672 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt @@ -0,0 +1,11 @@ +Renesas RZ/N1 SPI Controller + +This controller is based on the Synopsys DW Synchronous Serial Interface and +inherits all properties defined in snps,dw-apb-ssi.txt except for the +compatible property. + +Required properties: +- compatible : The device specific string followed by the generic RZ/N1 string. + Therefore it must be one of: + "renesas,r9a06g032-spi", "renesas,rzn1-spi" + "renesas,r9a06g033-spi", "renesas,rzn1-spi" -- 2.7.4
KASAN: use-after-free Read in key_put
Hello, syzbot found the following crash on: HEAD commit:a7f89616 Merge branch 'for-5.3-fixes' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=175eae1160 kernel config: https://syzkaller.appspot.com/x/.config?x=861a6f31647968de dashboard link: https://syzkaller.appspot.com/bug?extid=f3745a1dc2a5eb5040ef compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f3745a1dc2a5eb504...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in refcount_sub_and_test_checked+0x87/0x200 lib/refcount.c:182 Read of size 4 at addr 88805b89fc80 by task kworker/1:1/23 CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 5.3.0-rc8+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events key_garbage_collector Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482 kasan_report+0x12/0x17 mm/kasan/common.c:618 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:92 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] refcount_sub_and_test_checked+0x87/0x200 lib/refcount.c:182 refcount_dec_and_test_checked+0x1b/0x20 lib/refcount.c:220 key_put+0x20/0x90 security/keys/key.c:646 keyring_free_object+0x19/0x20 security/keys/keyring.c:389 assoc_array_destroy_subtree.part.0+0x1c5/0x4b0 lib/assoc_array.c:393 assoc_array_destroy_subtree lib/assoc_array.c:354 [inline] assoc_array_destroy+0x43/0x90 lib/assoc_array.c:444 keyring_destroy+0x259/0x2f0 security/keys/keyring.c:431 key_gc_unused_keys.constprop.0+0x313/0x5b0 security/keys/gc.c:136 key_garbage_collector+0x3f3/0x940 security/keys/gc.c:292 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 28788: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:493 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:466 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:501 slab_post_alloc_hook mm/slab.h:520 [inline] slab_alloc mm/slab.c:3319 [inline] kmem_cache_alloc+0x121/0x710 mm/slab.c:3483 kmem_cache_zalloc include/linux/slab.h:738 [inline] key_alloc+0x426/0x1110 security/keys/key.c:276 key_create_or_update+0x652/0xbe0 security/keys/key.c:924 __do_sys_add_key security/keys/keyctl.c:132 [inline] __se_sys_add_key security/keys/keyctl.c:72 [inline] __x64_sys_add_key+0x2bd/0x4f0 security/keys/keyctl.c:72 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 10344: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:455 kasan_slab_free+0xe/0x10 mm/kasan/common.c:463 __cache_free mm/slab.c:3425 [inline] kmem_cache_free+0x86/0x320 mm/slab.c:3693 key_gc_unused_keys.constprop.0+0x192/0x5b0 security/keys/gc.c:157 key_garbage_collector+0x3f3/0x940 security/keys/gc.c:292 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at 88805b89fc80 which belongs to the cache key_jar of size 304 The buggy address is located 0 bytes inside of 304-byte region [88805b89fc80, 88805b89fdb0) The buggy address belongs to the page: page:ea00016e27c0 refcount:1 mapcount:0 mapping:88821bc461c0 index:0x0 flags: 0x1fffc000200(slab) raw: 01fffc000200 ea00025c63c8 ea00023378c8 88821bc461c0 raw: 88805b89f080 0001000a page dumped because: kasan: bad access detected Memory state around the buggy address: 88805b89fb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88805b89fc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc 88805b89fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 88805b89fd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88805b89fd80: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information abo
[PATCH v2 2/4] dt-bindings: snps,dw-apb-ssi: Add optional clock domain information
Note in the bindings documentation that pclk should be renamed if a clock domain is used to enable the optional bus clock. Signed-off-by: Gareth Williams --- v2: Introduced this patch. --- Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt index f54c8c3..3ed08ee 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt @@ -16,7 +16,8 @@ Required properties: Optional properties: - clock-names : Contains the names of the clocks: "ssi_clk", for the core clock used to generate the external SPI clock. -"pclk", the interface clock, required for register access. +"pclk", the interface clock, required for register access. If a clock domain + used to enable this clock then it should be named "pclk_clkdomain". - cs-gpios : Specifies the gpio pins to be used for chipselects. - num-cs : The number of chipselects. If omitted, this will default to 4. - reg-io-width : The I/O register width (in bytes) implemented by this -- 2.7.4
[PATCH v2 0/4] spi: dw: Add basic runtime PM support
The Renesas RZ/N1 SPI Controller is based on the Synopsys DW SSI. This series enables power mode in the driver so the clock domain will enable the bus clock, adds the compatible string and updates the associated bindings documentation. v2: - Note that pclk should be renamed when using a clock domain in the bindings documentation. - Set spi_controller.auto_runtime_pm instead of using pm_runtime_get_sync. - Added pm_runtime_disable calls to dw_spi_remove_host and the error condition of dw_spi_add_host. Gareth Williams (1): dt-bindings: snps,dw-apb-ssi: Add optional clock domain information Phil Edworthy (3): dt: spi: Add Renesas RZ/N1 binding documentation spi: dw: Add basic runtime PM support spi: dw: Add compatible string for Renesas RZ/N1 SPI Controller Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt | 11 +++ Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt | 3 ++- drivers/spi/spi-dw-mmio.c | 1 + drivers/spi/spi-dw.c | 8 4 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt -- 2.7.4
[PATCH v2 4/4] spi: dw: Add compatible string for Renesas RZ/N1 SPI Controller
From: Phil Edworthy
The Renesas RZ/N1 SPI Controller is based on the Synopsys DW SSI, but has
additional registers for software CS control and DMA. This patch does not
address the changes required for DMA support, it simply adds the compatible
string. The CS registers are not needed as Linux can use gpios for the CS
signals.
Signed-off-by: Gareth Williams
Signed-off-by: Phil Edworthy
---
v2: no changes
---
drivers/spi/spi-dw-mmio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index edb3cf6..3640b01 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -225,6 +225,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] = {
{ .compatible = "mscc,ocelot-spi", .data = dw_spi_mscc_ocelot_init},
{ .compatible = "mscc,jaguar2-spi", .data = dw_spi_mscc_jaguar2_init},
{ .compatible = "amazon,alpine-dw-apb-ssi", .data = dw_spi_alpine_init},
+ { .compatible = "renesas,rzn1-spi", },
{ /* end of table */}
};
MODULE_DEVICE_TABLE(of, dw_spi_mmio_of_match);
--
2.7.4
[PATCH v2 3/4] spi: dw: Add basic runtime PM support
From: Phil Edworthy Enable runtime PM so that the clock used to access the registers in the peripheral is turned on using a clock domain. Signed-off-by: Phil Edworthy Signed-off-by: Gareth Williams --- v2: - set spi_controller.auto_runtime_pm instead of using pm_runtime_get_sync. - Added pm_runtime_disable calls to dw_spi_remove_host and the error condition of dw_spi_add_host. --- drivers/spi/spi-dw.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c index 9a49e07..54ed6eb 100644 --- a/drivers/spi/spi-dw.c +++ b/drivers/spi/spi-dw.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -493,10 +494,13 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws) master->dev.of_node = dev->of_node; master->dev.fwnode = dev->fwnode; master->flags = SPI_MASTER_GPIO_SS; + master->auto_runtime_pm = true; if (dws->set_cs) master->set_cs = dws->set_cs; + pm_runtime_enable(dev); + /* Basic HW init */ spi_hw_init(dev, dws); @@ -525,6 +529,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws) spi_enable_chip(dws, 0); free_irq(dws->irq, master); err_free_master: + pm_runtime_disable(dev); spi_controller_put(master); return ret; } @@ -539,6 +544,9 @@ void dw_spi_remove_host(struct dw_spi *dws) spi_shutdown_chip(dws); + if (dws->master) + pm_runtime_disable(&dws->master->dev); + free_irq(dws->irq, dws->master); } EXPORT_SYMBOL_GPL(dw_spi_remove_host); -- 2.7.4
[RFC PATCH v3 0/6] Enable ptp_kvm for arm64
kvm ptp targets to provide high precision time sync between guest
and host in virtualization environment. This patch enable kvm ptp
for arm64.
This patch set base on [1][2][3]
change log:
from v2 to v3:
(1) fix some issues in commit log.
(2) add some receivers in send list.
from v1 to v2:
(1) move arch-specific code from arch/ to driver/ptp/
(2) offer mechanism to inform userspace if ptp_kvm service is
available.
(3) separate ptp_kvm code for arm64 into hypervisor part and
guest part.
(4) add API to expose monotonic clock and counter value.
(5) refine code: remove no necessary part and reconsitution.
[1]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=125ea89e4a21e2fc5235410f966a996a1a7148bf
[2]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06
[3]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=6597490e005d0eeca8ed8c1c1d7b4318ee014681
Jianyong Wu (6):
psci: Export psci_ops.conduit symbol as modules will use it.
ptp: Reorganize ptp_kvm modules to make it arch-independent.
timekeeping: Expose API allowing retrival of current clocksource and
counter value
psci: Add hvc call service for ptp_kvm.
ptp: arm64: Enable ptp_kvm for arm64
kvm: arm64: Add capability check extension for ptp_kvm
drivers/firmware/psci/psci.c | 6 ++
drivers/ptp/Kconfig | 2 +-
drivers/ptp/Makefile | 1 +
drivers/ptp/{ptp_kvm.c => kvm_ptp.c} | 77 ++--
drivers/ptp/ptp_kvm_arm64.c | 82 ++
drivers/ptp/ptp_kvm_x86.c| 87
include/asm-generic/ptp_kvm.h| 12
include/linux/arm-smccc.h| 14 -
include/linux/psci.h | 1 +
include/linux/timekeeping.h | 3 +
include/uapi/linux/kvm.h | 1 +
kernel/time/timekeeping.c| 13 +
virt/kvm/arm/arm.c | 1 +
virt/kvm/arm/psci.c | 17 ++
14 files changed, 256 insertions(+), 61 deletions(-)
rename drivers/ptp/{ptp_kvm.c => kvm_ptp.c} (63%)
create mode 100644 drivers/ptp/ptp_kvm_arm64.c
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/asm-generic/ptp_kvm.h
--
2.17.1
[RFC PATCH v3 1/6] psci: Export psci_ops.conduit symbol as modules will use it.
If arm_smccc_1_1_invoke used in modules, psci_ops.conduit should
be export.
Signed-off-by: Jianyong Wu
---
drivers/firmware/psci/psci.c | 6 ++
include/linux/arm-smccc.h| 2 +-
include/linux/psci.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f82ccd39a913..35c4eaab1451 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -212,6 +212,12 @@ static unsigned long psci_migrate_info_up_cpu(void)
0, 0, 0);
}
+enum psci_conduit psci_get_conduit(void)
+{
+ return psci_ops.conduit;
+}
+EXPORT_SYMBOL(psci_get_conduit);
+
static void set_conduit(enum psci_conduit conduit)
{
switch (conduit) {
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 552cbd49abe8..a6e4d3e3d10a 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -357,7 +357,7 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned
long a1,
* The return value also provides the conduit that was used.
*/
#define arm_smccc_1_1_invoke(...) ({ \
- int method = psci_ops.conduit; \
+ int method = psci_get_conduit();\
switch (method) { \
case PSCI_CONDUIT_HVC: \
arm_smccc_1_1_hvc(__VA_ARGS__); \
diff --git a/include/linux/psci.h b/include/linux/psci.h
index a8a15613c157..e5cedc986049 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -42,6 +42,7 @@ struct psci_operations {
enum smccc_version smccc_version;
};
+extern enum psci_conduit psci_get_conduit(void);
extern struct psci_operations psci_ops;
#if defined(CONFIG_ARM_PSCI_FW)
--
2.17.1
[RFC PATCH v3 5/6] ptp: arm64: Enable ptp_kvm for arm64
Currently in arm64 virtualization environment, there is no mechanism to keep time sync between guest and host. Time in guest will drift compared with host after boot up as they may both use third party time sources to correct their time respectively. The time deviation will be in order of milliseconds but some scenarios ask for higher time precision, like in cloud envirenment, we want all the VMs running in the host aquire the same level accuracy from host clock. Use of kvm ptp clock, which choose the host clock source clock as a reference clock to sync time clock between guest and host has been adopted by x86 which makes the time sync order from milliseconds to nanoseconds. This patch enable kvm ptp on arm64 and we get the similar clock drift as found with x86 with kvm ptp. Test result comparison between with kvm ptp and without it in arm64 are as follows. This test derived from the result of command 'chronyc sources'. we should take more cure of the last sample column which shows the offset between the local clock and the source at the last measurement. no kvm ptp in guest: MS Name/IP address Stratum Poll Reach LastRx Last sample ^* dns1.synet.edu.cn 2 6 37713 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37721 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37729 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37737 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37745 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37753 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37761 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37712 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 37720 -130us[ +796us] +/- 21ms in host: MS Name/IP address Stratum Poll Reach LastRx Last sample ^* 120.25.115.20 2 7 37772 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 37792 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 37722 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 37743 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 37763 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 37783 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms The dns1.synet.edu.cn is the network reference clock for guest and 120.25.115.20 is the network reference clock for host. we can't get the clock error between guest and host directly, but a roughly estimated value will be in order of hundreds of us to ms. with kvm ptp in guest: chrony has been disabled in host to remove the disturb by network clock. MS Name/IP address Stratum Poll Reach LastRx Last sample * PHC00 3 377 8 -7ns[ +1ns] +/-3ns * PHC00 3 377 8 +1ns[ +16ns] +/-3ns * PHC00 3 377 6 -4ns[ -0ns] +/-6ns * PHC00 3 377 6 -8ns[ -12ns] +/-5ns * PHC00 3 377 5 +2ns[ +4ns] +/-4ns * PHC00 3 37713 +2ns[ +4ns] +/-4ns * PHC00 3 37712 -4ns[ -6ns] +/-4ns * PHC00 3 37711 -8ns[ -11ns] +/-6ns * PHC00 3 37710-14ns[ -20ns] +/-4ns * PHC00 3 377 8 +4ns[ +5ns] +/-4ns The PHC0 is the ptp clock which choose the host clock as its source clock. So we can be sure to say that the clock error between host and guest is in order of ns. Signed-off-by: Jianyong Wu --- drivers/ptp/Kconfig | 2 +- drivers/ptp/kvm_ptp.c | 2 +- drivers/ptp/ptp_kvm_arm64.c | 82 + 3 files changed, 84 insertions(+), 2 deletions(-) create mode 100644 drivers/ptp/ptp_kvm_arm64.c diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index 9b8fee5178e8..e032fafdafa7 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH config PTP_1588_CLOCK_KVM tristate "KVM virtual PTP clock" depends on PTP_1588_CLOCK - depends on KVM_GUEST && X86 + depends on KVM_GUEST && X86 || ARM64 default y help This driver adds support for using kvm infrastructure as a PTP diff --git a/drivers/p
[RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
This patch is the base of ptp_kvm for arm64.
ptp_kvm modules will call hvc to get this service.
The service offers real time and counter cycle of host for guest.
Signed-off-by: Jianyong Wu
---
include/linux/arm-smccc.h | 12
virt/kvm/arm/psci.c | 17 +
2 files changed, 29 insertions(+)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a6e4d3e3d10a..bc0cdad10f35 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -94,6 +94,7 @@
/* KVM "vendor specific" services */
#define ARM_SMCCC_KVM_FUNC_FEATURES0
+#define ARM_SMCCC_KVM_PTP 1
#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
#define ARM_SMCCC_KVM_NUM_FUNCS128
@@ -103,6 +104,17 @@
ARM_SMCCC_OWNER_VENDOR_HYP, \
ARM_SMCCC_KVM_FUNC_FEATURES)
+/*
+ * This ID used for virtual ptp kvm clock and it will pass second value
+ * and nanosecond value of host real time and system counter by vcpu
+ * register to guest.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32,\
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_PTP)
+
#ifndef __ASSEMBLY__
#include
diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
index 0debf49bf259..2c5d53817a28 100644
--- a/virt/kvm/arm/psci.c
+++ b/virt/kvm/arm/psci.c
@@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 func_id = smccc_get_function(vcpu);
u32 val[4] = {};
u32 option;
+ struct timespec *ts;
+ struct system_counterval_t sc;
val[0] = SMCCC_RET_NOT_SUPPORTED;
@@ -431,6 +433,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
break;
+ /*
+* This will used for virtual ptp kvm clock. three
+* values will be passed back.
+* reg0 stores seconds of host real time;
+* reg1 stores nanoseconds of host real time;
+* reg2 stores system counter cycle value.
+*/
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ getnstimeofday(ts);
+ get_current_counterval(&sc);
+ val[0] = ts->tv_sec;
+ val[1] = ts->tv_nsec;
+ val[2] = sc.cycles;
+ val[3] = 0;
+ break;
default:
return kvm_psci_call(vcpu);
}
--
2.17.1
[RFC PATCH v3 3/6] timekeeping: Expose API allowing retrival of current clocksource and counter value
>From Marc Zyngier
A number of PTP drivers (such as ptp-kvm) are assuming what the
current clock source is, which could lead to interesting effects on
systems where the clocksource can change depending on external events.
For this purpose, add a new API that retrives both the current
monotonic clock as well as its counter value.
>From Jianyong Wu: export this API then modules can use it.
Signed-off-by: Marc Zyngier
Signed-off-by: Jianyong Wu
---
include/linux/timekeeping.h | 3 +++
kernel/time/timekeeping.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a8ab0f143ac4..a5389adaa8bc 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -247,6 +247,9 @@ extern int get_device_system_crosststamp(
struct system_time_snapshot *history,
struct system_device_crosststamp *xtstamp);
+/* Obtain current monotonic clock and its counter value */
+extern void get_current_counterval(struct system_counterval_t *sc);
+
/*
* Simultaneously snapshot realtime and monotonic raw clocks
*/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44b726bab4bd..07a0969625b1 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1098,6 +1098,19 @@ static bool cycle_between(u64 before, u64 test, u64
after)
return false;
}
+/**
+ * get_current_counterval - Snapshot the current clocksource and counter value
+ * @sc:Pointer to a struct containing the current clocksource and its
value
+ */
+void get_current_counterval(struct system_counterval_t *sc)
+{
+ struct timekeeper *tk = &tk_core.timekeeper;
+
+ sc->cs = READ_ONCE(tk->tkr_mono.clock);
+ sc->cycles = sc->cs->read(sc->cs);
+}
+EXPORT_SYMBOL_GPL(get_current_counterval);
+
/**
* get_device_system_crosststamp - Synchronously capture system/device
timestamp
* @get_time_fn: Callback to get simultaneous device time and
--
2.17.1
[RFC PATCH v3 6/6] kvm: arm64: Add capability check extension for ptp_kvm
Let userspace check if there is kvm ptp service in host.
before VMs migrate to a another host, VMM may check if this
cap is available to determine the migration behaviour.
Signed-off-by: Jianyong Wu
Suggested-by: Marc Zyngier
---
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2fe12b40d503..a0bff6002bd9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_SVE 170
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
+#define KVM_CAP_ARM_KVM_PTP 173
#ifdef KVM_CAP_IRQ_ROUTING
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index bd5c55916d0d..8085160b 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -201,6 +201,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MP_STATE:
case KVM_CAP_IMMEDIATE_EXIT:
case KVM_CAP_VCPU_EVENTS:
+ case KVM_CAP_ARM_KVM_PTP:
r = 1;
break;
case KVM_CAP_ARM_SET_DEVICE_ADDR:
--
2.17.1
[RFC PATCH v3 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent.
Currently, ptp_kvm modules implementation is only for x86 which includs
large part of arch-specific code. This patch move all of those code
into sole arch related file in the same directory.
Signed-off-by: Jianyong Wu
---
drivers/ptp/Makefile | 1 +
drivers/ptp/{ptp_kvm.c => kvm_ptp.c} | 77 ++--
drivers/ptp/ptp_kvm_x86.c| 87
include/asm-generic/ptp_kvm.h| 12
4 files changed, 118 insertions(+), 59 deletions(-)
rename drivers/ptp/{ptp_kvm.c => kvm_ptp.c} (63%)
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/asm-generic/ptp_kvm.h
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index 677d1d178a3e..8f27ba302e31 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -4,6 +4,7 @@
#
ptp-y := ptp_clock.o ptp_chardev.o ptp_sysfs.o
+ptp_kvm-y := ptp_kvm_$(ARCH).o kvm_ptp.o
obj-$(CONFIG_PTP_1588_CLOCK) += ptp.o
obj-$(CONFIG_PTP_1588_CLOCK_DTE) += ptp_dte.o
obj-$(CONFIG_PTP_1588_CLOCK_IXP46X)+= ptp_ixp46x.o
diff --git a/drivers/ptp/ptp_kvm.c b/drivers/ptp/kvm_ptp.c
similarity index 63%
rename from drivers/ptp/ptp_kvm.c
rename to drivers/ptp/kvm_ptp.c
index fc7d0b77e118..d8f215186904 100644
--- a/drivers/ptp/ptp_kvm.c
+++ b/drivers/ptp/kvm_ptp.c
@@ -8,12 +8,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
-#include
#include
+#include
#include
@@ -24,56 +24,29 @@ struct kvm_ptp_clock {
DEFINE_SPINLOCK(kvm_ptp_lock);
-static struct pvclock_vsyscall_time_info *hv_clock;
-
-static struct kvm_clock_pairing clock_pair;
-static phys_addr_t clock_pair_gpa;
-
static int ptp_kvm_get_time_fn(ktime_t *device_time,
struct system_counterval_t *system_counter,
void *ctx)
{
- unsigned long ret;
+ unsigned long ret, cycle;
struct timespec64 tspec;
- unsigned version;
- int cpu;
- struct pvclock_vcpu_time_info *src;
+ struct clocksource *cs;
spin_lock(&kvm_ptp_lock);
preempt_disable_notrace();
- cpu = smp_processor_id();
- src = &hv_clock[cpu].pvti;
-
- do {
- /*
-* We are using a TSC value read in the hosts
-* kvm_hc_clock_pairing handling.
-* So any changes to tsc_to_system_mul
-* and tsc_shift or any other pvclock
-* data invalidate that measurement.
-*/
- version = pvclock_read_begin(src);
-
- ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
-clock_pair_gpa,
-KVM_CLOCK_PAIRING_WALLCLOCK);
- if (ret != 0) {
- pr_err_ratelimited("clock pairing hypercall ret %lu\n",
ret);
- spin_unlock(&kvm_ptp_lock);
- preempt_enable_notrace();
- return -EOPNOTSUPP;
- }
-
- tspec.tv_sec = clock_pair.sec;
- tspec.tv_nsec = clock_pair.nsec;
- ret = __pvclock_read_cycles(src, clock_pair.tsc);
- } while (pvclock_read_retry(src, version));
+ ret = kvm_arch_ptp_get_clock_fn(&cycle, &tspec, &cs);
+ if (ret != 0) {
+ pr_err_ratelimited("clock pairing hypercall ret %lu\n", ret);
+ spin_unlock(&kvm_ptp_lock);
+ preempt_enable_notrace();
+ return -EOPNOTSUPP;
+ }
preempt_enable_notrace();
- system_counter->cycles = ret;
- system_counter->cs = &kvm_clock;
+ system_counter->cycles = cycle;
+ system_counter->cs = cs;
*device_time = timespec64_to_ktime(tspec);
@@ -116,17 +89,13 @@ static int ptp_kvm_gettime(struct ptp_clock_info *ptp,
struct timespec64 *ts)
spin_lock(&kvm_ptp_lock);
- ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
-clock_pair_gpa,
-KVM_CLOCK_PAIRING_WALLCLOCK);
+ ret = kvm_arch_ptp_get_clock(&tspec);
if (ret != 0) {
pr_err_ratelimited("clock offset hypercall ret %lu\n", ret);
spin_unlock(&kvm_ptp_lock);
return -EOPNOTSUPP;
}
- tspec.tv_sec = clock_pair.sec;
- tspec.tv_nsec = clock_pair.nsec;
spin_unlock(&kvm_ptp_lock);
memcpy(ts, &tspec, sizeof(struct timespec64));
@@ -166,21 +135,11 @@ static void __exit ptp_kvm_exit(void)
static int __init ptp_kvm_init(void)
{
- long ret;
-
- if (!kvm_para_available())
- return -ENODEV;
-
- clock_pair_gpa = slow_virt_to_phys(&clock_pair);
- hv_clock = pvclock_get_pvti_cpu0_va();
+ int ret;
- if (!hv_clock)
- return -ENODEV;
-
- ret = kvm_hypercall2(KVM_HC_CLO
Re: printk meeting at LPC
On (09/18/19 09:33), John Ogness wrote: > > I expect sysrq to be the only valid use of "synchronous state" other > than oops/panic. Although I suppose PeterZ would like a boot argument to > always run the consoles in this state. Yes, there might be more cases when we need sync printk(). Like lockdep splats, KASAN warnings, PM debugging, etc. Those things sometimes come right before "truly bad stuff". > > For instance, tty/sysrq must be able to switch printk emergency > > on/off. > > The switch/flush _will_ be visible. But not the state. So, for example, > it won't be possible for some random driver to determine if we are in an > emergency state. (Well, I don't know if oops_in_progress will really > disappear. But at least the printk/console stuff will no longer rely on > it.) [..] > Thanks for bringing up that RFC thread again. I haven't looked at it in > over a year. I will go through it again to see if there is anything I've > overlooked. Particularly the suspend stuff. That thread most likely is incomplet and incorrekt in some parts; shouldn't be taken too seriously, I guess. -ss
Re: printk meeting at LPC
On (09/18/19 09:42), John Ogness wrote: > > It's going to be a bit harder when we have per-console kthread. > > Each console has its own iterator. This iterators will need to advance, > regardless if the message was printed via write() or write_atomic(). Great. ->atomic_write() path will make sure that kthread is parked or will those compete for uart port? -ss
Re: [PATCH v2 0/7] counter: Simplify count_read/count_write/signal_read
On Wed, Sep 18, 2019 at 04:52:41PM +0900, William Breathitt Gray wrote: > Changes in v2: > - Update the rest of the drivers under drivers/counter Jonathan, The TI eQEP driver also needs a patch for these changes if this patchset is merged. How would you like to handle the merge? We have an full cycle until the 5.5 merge window, so I can keep this patchset in my personal repository, adding in the ChromeOS EC driver and Intel QEP driver when they are ready, then send you a git pull request during the 5.5 merge window. Or we can keep going as usual and merge this into your IIO repository, then handle the TI eQEP driver when the time comes to merge. William Breathitt Gray > The changes in this patchset will not affect the userspace interface. > Rather, these changes are intended to simplify the kernelspace Counter > callbacks for counter device driver authors. > > The following main changes are proposed: > > * Retire the opaque counter_count_read_value/counter_count_write_value > structures and simply represent count data as an unsigned integer. > > * Retire the opaque counter_signal_read_value structure and represent > Signal data as a counter_signal_value enum. > > These changes should reduce some complexity and code in the use and > implementation of the count_read, count_write, and signal_read > callbacks. > > The opaque structures for Count data and Signal data were introduced > originally in anticipation of supporting various representations of > counter data (e.g. arbitrary-precision tallies, floating-point spherical > coordinate positions, etc). However, with the counter device drivers > that have appeared, it's become apparent that utilizing opaque > structures in kernelspace is not the best approach to take. > > I believe it is best to let userspace applications decide how to > interpret the count data they receive. There are a couple of reasons why > it would be good to do so: > > * Users use their devices in unexpected ways. > > For example, a quadrature encoder counter device is typically used to > keep track of the position of a motor, but a user could set the device > in a pulse-direction mode and instead use it to count sporadic rising > edges from an arbitrary signal line unrelated to positioning. Users > should have the freedom to decide what their data represents. > > * Most counter devices represent data as unsigned integers anyway. > > For example, whether the device is a tally counter or position > counter, the count data is represented to the user as an unsigned > integer value. So specifying that one device is representing tallies > while the other specifies positions does not provide much utility from > an interface perspective. > > For these reasons, the count_read and count_write callbacks have been > redefined to pass count data directly as unsigned long instead of passed > via opaque structures: > > count_read(struct counter_device *counter, >struct counter_count *count, unsigned long *val); > count_write(struct counter_device *counter, > struct counter_count *count, unsigned long val); > > Similarly, the signal_read is redefined to pass Signal data directly as > a counter_signal_value enum instead of via an opaque structure: > > signal_read(struct counter_device *counter, > struct counter_signal *signal, > enum counter_signal_value *val); > > The counter_signal_value enum is simply the counter_signal_level enum > redefined to remove the references to the Signal data "level" data type. > > William Breathitt Gray (7): > counter: Simplify the count_read and count_write callbacks > counter: Simplify the signal_read callback > docs: driver-api: generic-counter: Update Count and Signal data types > counter: 104-quad-8: Update count_read/count_write/signal_read > callbacks > counter: ftm-quaddec: Update count_read and count_write callbacks > counter: stm32-lptimer-cnt: Update count_read callback > counter: stm32-timer-cnt: Update count_read and count_write callbacks > > Documentation/driver-api/generic-counter.rst | 22 ++-- > drivers/counter/104-quad-8.c | 33 ++ > drivers/counter/counter.c| 101 +++ > drivers/counter/ftm-quaddec.c| 14 +-- > drivers/counter/stm32-lptimer-cnt.c | 5 +- > drivers/counter/stm32-timer-cnt.c| 17 +--- > include/linux/counter.h | 74 ++ > 7 files changed, 53 insertions(+), 213 deletions(-) > > -- > 2.23.0
[PATCH] dt-bindings: net: remove un-implemented property
The `adi,disable-energy-detect` property was implemented in an initial
version of the `adin` driver series, but after a review it was discarded in
favor of implementing the ETHTOOL_PHY_EDPD phy-tunable option.
With the ETHTOOL_PHY_EDPD control, it's possible to disable/enable
Energy-Detect-Power-Down for the `adin` PHY, so this device-tree is not
needed.
Fixes: 767078132ff9 ("dt-bindings: net: add bindings for ADIN PHY driver")
Signed-off-by: Alexandru Ardelean
---
Documentation/devicetree/bindings/net/adi,adin.yaml | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml
b/Documentation/devicetree/bindings/net/adi,adin.yaml
index 69375cb28e92..d95cc691a65f 100644
--- a/Documentation/devicetree/bindings/net/adi,adin.yaml
+++ b/Documentation/devicetree/bindings/net/adi,adin.yaml
@@ -36,12 +36,6 @@ properties:
enum: [ 4, 8, 12, 16, 20, 24 ]
default: 8
- adi,disable-energy-detect:
-description: |
- Disables Energy Detect Powerdown Mode (default disabled, i.e energy
detect
- is enabled if this property is unspecified)
-type: boolean
-
examples:
- |
ethernet {
@@ -68,6 +62,5 @@ examples:
reg = <1>;
adi,fifo-depth-bits = <16>;
-adi,disable-energy-detect;
};
};
--
2.20.1
Re: [RFC PATCH] memalloc_noio: update the comment to make it cleaner
On Wed 18-09-19 16:02:52, Xiubo Li wrote:
> On 2019/9/18 15:25, Michal Hocko wrote:
> > On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
> > > From: Xiubo Li
> > >
> > > The GFP_NOIO means all further allocations will implicitly drop
> > > both __GFP_IO and __GFP_FS flags and so they are safe for both the
> > > IO critical section and the the critical section from the allocation
> > > recursion point of view. Not only the __GFP_IO, which a bit confusing
> > > when reading the code or using the save/restore pair.
> > Historically GFP_NOIO has always implied GFP_NOFS as well. I can imagine
> > that this might come as an surprise for somebody not familiar with the
> > code though.
>
> Yeah, it true.
>
> > I am wondering whether your update of the documentation
> > would be better off at __GFP_FS, __GFP_IO resp. GFP_NOFS, GFP_NOIO level.
> > This interface is simply a way to set a scoped NO{IO,FS} context.
>
> The "Documentation/core-api/gfp_mask-from-fs-io.rst" is already very detail
> about them all.
>
> This fixing just means to make sure that it won't surprise someone who is
> having a quickly through some code and not familiar much about the detail.
> It may make not much sense ?
Ohh, I do not think this would be senseless. I just think that the NOIO
implying NOFS as well should be described at the level where they are
documented rather than the api you have chosen.
--
Michal Hocko
SUSE Labs
[PATCH] serial: sprd: Add polling IO support
In order to access the UART without the interrupts, the kernel uses
the basic polling methods for IO with the device. With these methods
implemented, it is now possible to enable kgdb during early boot over serial.
Signed-off-by: Lanqing Liu
---
drivers/tty/serial/sprd_serial.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 73d71a4..579ab41 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -911,6 +911,24 @@ static void sprd_pm(struct uart_port *port, unsigned int
state,
}
}
+#ifdef CONFIG_CONSOLE_POLL
+static int sprd_poll_get_char(struct uart_port *port)
+{
+ while (!(serial_in(port, SPRD_STS1) & SPRD_RX_FIFO_CNT_MASK))
+ cpu_relax();
+
+ return serial_in(port, SPRD_RXD);
+}
+
+static void sprd_poll_put_char(struct uart_port *port, unsigned char ch)
+{
+ while (serial_in(port, SPRD_STS1) & SPRD_TX_FIFO_CNT_MASK)
+ cpu_relax();
+
+ serial_out(port, SPRD_TXD, ch);
+}
+#endif
+
static const struct uart_ops serial_sprd_ops = {
.tx_empty = sprd_tx_empty,
.get_mctrl = sprd_get_mctrl,
@@ -928,6 +946,10 @@ static void sprd_pm(struct uart_port *port, unsigned int
state,
.config_port = sprd_config_port,
.verify_port = sprd_verify_port,
.pm = sprd_pm,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = sprd_poll_get_char,
+ .poll_put_char = sprd_poll_put_char,
+#endif
};
#ifdef CONFIG_SERIAL_SPRD_CONSOLE
--
1.9.1
Re: [RFC PATCH] memalloc_noio: update the comment to make it cleaner
On 2019/9/18 16:14, Michal Hocko wrote:
On Wed 18-09-19 16:02:52, Xiubo Li wrote:
On 2019/9/18 15:25, Michal Hocko wrote:
On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
From: Xiubo Li
The GFP_NOIO means all further allocations will implicitly drop
both __GFP_IO and __GFP_FS flags and so they are safe for both the
IO critical section and the the critical section from the allocation
recursion point of view. Not only the __GFP_IO, which a bit confusing
when reading the code or using the save/restore pair.
Historically GFP_NOIO has always implied GFP_NOFS as well. I can imagine
that this might come as an surprise for somebody not familiar with the
code though.
Yeah, it true.
I am wondering whether your update of the documentation
would be better off at __GFP_FS, __GFP_IO resp. GFP_NOFS, GFP_NOIO level.
This interface is simply a way to set a scoped NO{IO,FS} context.
The "Documentation/core-api/gfp_mask-from-fs-io.rst" is already very detail
about them all.
This fixing just means to make sure that it won't surprise someone who is
having a quickly through some code and not familiar much about the detail.
It may make not much sense ?
Ohh, I do not think this would be senseless. I just think that the NOIO
implying NOFS as well should be described at the level where they are
documented rather than the api you have chosen.
Hmm, yeah totally agree :-)
Thanks
BRs
Re: [PATCH 3/3] regulator: core: make regulator_register() EPROBE_DEFER aware
On 19-09-17 17:57, Dmitry Torokhov wrote: > On Tue, Sep 17, 2019 at 4:42 PM Marco Felsch wrote: > > > > Sometimes it can happen that the regulator_of_get_init_data() can't > > retrieve the config due to a not probed device the regulator depends on. > > Fix that by checking the return value of of_parse_cb() and return > > EPROBE_DEFER in such cases. > > Treating EPROBE_DEFER in a special way is usually wrong. > regulator_of_get_init_data() may fail for multiple reasons (no memory, > invalid DT, etc, etc). All of them should abort instantiating > regulator. Those errors are handled but the behaviour of this funciton is to return NULL in such errors which is fine for the caller of this function. I only want to handle EPROBE_DEFER special.. Regards, Marco > Thanks. > > -- > Dmitry > -- 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- |
[PATCH stable 4.4 net] net: rds: Fix NULL ptr use in rds_tcp_kill_sock
After the commit c4e97b06cfdc ("net: rds: force to destroy
connection if t_sock is NULL in rds_tcp_kill_sock()."),
it introduced null-ptr-deref in rds_tcp_kill_sock as below:
BUG: KASAN: null-ptr-deref on address 0020
Read of size 8 by task kworker/u16:10/910
CPU: 3 PID: 910 Comm: kworker/u16:10 Not tainted 4.4.178+ #3
Hardware name: linux,dummy-virt (DT)
Workqueue: netns cleanup_net
Call trace:
[] dump_backtrace+0x0/0x618
[] show_stack+0x38/0x60
[] dump_stack+0x1a8/0x230
[] kasan_report_error+0xc8c/0xfc0
[] kasan_report+0x94/0xd8
[] __asan_load8+0x88/0x150
[] rds_tcp_dev_event+0x734/0xb48
[] raw_notifier_call_chain+0x150/0x1e8
[] call_netdevice_notifiers_info+0x90/0x110
[] netdev_run_todo+0x2f4/0xb08
[] rtnl_unlock+0x2c/0x48
[] default_device_exit_batch+0x444/0x528
[] ops_exit_list+0x1c0/0x240
[] cleanup_net+0x738/0xbf8
[] process_one_work+0x96c/0x13e0
[] worker_thread+0x7e0/0x1910
[] kthread+0x304/0x390
[] ret_from_fork+0x10/0x50
If the first loop add the tc->t_sock = NULL to the tmp_list,
1). list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node)
then the second loop is to find connections to destroy, tc->t_sock
might equal NULL, and tc->t_sock->sk happens null-ptr-deref.
2). list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node)
Fixes: c4e97b06cfdc ("net: rds: force to destroy connection if t_sock is NULL
in rds_tcp_kill_sock().")
Signed-off-by: Mao Wenan
---
net/rds/tcp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 554d4b461983..c10622a9321c 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -352,9 +352,11 @@ static void rds_tcp_kill_sock(struct net *net)
}
spin_unlock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) {
- sk = tc->t_sock->sk;
- sk->sk_prot->disconnect(sk, 0);
- tcp_done(sk);
+ if (tc->t_sock) {
+ sk = tc->t_sock->sk;
+ sk->sk_prot->disconnect(sk, 0);
+ tcp_done(sk);
+ }
if (tc->conn->c_passive)
rds_conn_destroy(tc->conn->c_passive);
rds_conn_destroy(tc->conn);
--
2.20.1
Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
On 18/09/19 10:07, Jianyong Wu wrote: > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: > + getnstimeofday(ts); This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and split the 64-bit seconds value between val[0] and val[1]. However, it seems to me that the new function is not needed and you can just use ktime_get_snapshot. You'll get the time in systime_snapshot->real and the cycles value in systime_snapshot->cycles. > + get_current_counterval(&sc); > + val[0] = ts->tv_sec; > + val[1] = ts->tv_nsec; > + val[2] = sc.cycles; > + val[3] = 0; > + break; This should return a guest-cycles value. If the cycles values always the same between the host and the guest on ARM, then okay. If not, you have to apply whatever offset exists. Thanks, Paolo
[PATCH v6 3/4] ASoC: rockchip_max98090: Add dai_link for HDMI
Use two dai_links. One for HDMI and one for max98090.
With this setup, audio can play to speaker and HDMI selectively.
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/rockchip/rockchip_max98090.c | 96 --
1 file changed, 73 insertions(+), 23 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_max98090.c
b/sound/soc/rockchip/rockchip_max98090.c
index c5fc24675a33..c82948e383da 100644
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,6 +42,7 @@ static const struct snd_soc_dapm_widget rk_dapm_widgets[] = {
SND_SOC_DAPM_MIC("Headset Mic", NULL),
SND_SOC_DAPM_MIC("Int Mic", NULL),
SND_SOC_DAPM_SPK("Speaker", NULL),
+ SND_SOC_DAPM_LINE("HDMI", NULL),
};
static const struct snd_soc_dapm_route rk_audio_map[] = {
@@ -52,6 +54,7 @@ static const struct snd_soc_dapm_route rk_audio_map[] = {
{"Headphone", NULL, "HPR"},
{"Speaker", NULL, "SPKL"},
{"Speaker", NULL, "SPKR"},
+ {"HDMI", NULL, "TX"},
};
static const struct snd_kcontrol_new rk_mc_controls[] = {
@@ -59,6 +62,7 @@ static const struct snd_kcontrol_new rk_mc_controls[] = {
SOC_DAPM_PIN_SWITCH("Headset Mic"),
SOC_DAPM_PIN_SWITCH("Int Mic"),
SOC_DAPM_PIN_SWITCH("Speaker"),
+ SOC_DAPM_PIN_SWITCH("HDMI"),
};
static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
@@ -92,38 +96,63 @@ static int rk_aif1_hw_params(struct snd_pcm_substream
*substream,
ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
SND_SOC_CLOCK_OUT);
- if (ret < 0) {
- dev_err(codec_dai->dev, "Can't set codec clock %d\n", ret);
+ if (ret) {
+ dev_err(cpu_dai->dev, "Can't set cpu dai clock %d\n", ret);
return ret;
}
+ /* HDMI codec dai does not need to set sysclk. */
+ if (!strcmp(rtd->dai_link->name, "HDMI"))
+ return 0;
+
ret = snd_soc_dai_set_sysclk(codec_dai, 0, mclk,
SND_SOC_CLOCK_IN);
- if (ret < 0) {
- dev_err(codec_dai->dev, "Can't set codec clock %d\n", ret);
+ if (ret) {
+ dev_err(codec_dai->dev, "Can't set codec dai clock %d\n", ret);
return ret;
}
- return ret;
+ return 0;
}
static const struct snd_soc_ops rk_aif1_ops = {
.hw_params = rk_aif1_hw_params,
};
-SND_SOC_DAILINK_DEFS(hifi,
+SND_SOC_DAILINK_DEFS(analog,
DAILINK_COMP_ARRAY(COMP_EMPTY()),
DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "HiFi")),
DAILINK_COMP_ARRAY(COMP_EMPTY()));
-static struct snd_soc_dai_link rk_dailink = {
- .name = "max98090",
- .stream_name = "Audio",
- .ops = &rk_aif1_ops,
- /* set max98090 as slave */
- .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBS_CFS,
- SND_SOC_DAILINK_REG(hifi),
+SND_SOC_DAILINK_DEFS(hdmi,
+ DAILINK_COMP_ARRAY(COMP_EMPTY()),
+ DAILINK_COMP_ARRAY(COMP_CODEC(HDMI_CODEC_DRV_NAME, "i2s-hifi")),
+ DAILINK_COMP_ARRAY(COMP_EMPTY()));
+
+enum {
+ DAILINK_MAX98090,
+ DAILINK_HDMI,
+};
+
+/* max98090 and HDMI codec dai_link */
+static struct snd_soc_dai_link rk_dailinks[] = {
+ [DAILINK_MAX98090] = {
+ .name = "max98090",
+ .stream_name = "Analog",
+ .ops = &rk_aif1_ops,
+ /* set max98090 as slave */
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBS_CFS,
+ SND_SOC_DAILINK_REG(analog),
+ },
+ [DAILINK_HDMI] = {
+ .name = "HDMI",
+ .stream_name = "HDMI",
+ .ops = &rk_aif1_ops,
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBS_CFS,
+ SND_SOC_DAILINK_REG(hdmi),
+ }
};
static int rk_98090_headset_init(struct snd_soc_component *component);
@@ -136,8 +165,8 @@ static struct snd_soc_aux_dev rk_98090_headset_dev = {
static struct snd_soc_card snd_soc_card_rk = {
.name = "ROCKCHIP-I2S",
.owner = THIS_MODULE,
- .dai_link = &rk_dailink,
- .num_links = 1,
+ .dai_link = rk_dailinks,
+ .num_links = ARRAY_SIZE(rk_dailinks),
.aux_dev = &rk_98090_headset_dev,
.num_aux_devs = 1,
.dapm_widgets = rk_dapm_widgets,
@@ -173,27 +202,48 @@ static int snd_rk_mc_probe(struct platform_device *pdev)
int ret = 0;
struct snd_soc_card *card = &snd_soc_card_rk;
struct device_node *np = pdev->dev.of_node;
+ struct device_node *np_analog;
+ struct device_node *np_cpu;
+ struct of_phandle_args args;
/* register the soc card */
card->dev = &pdev->dev;
- rk_dail
[PATCH v6 4/4] ASoC: rockchip_max98090: Add HDMI jack support
In machine driver, create a jack and let hdmi-codec report jack status.
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/rockchip/Kconfig | 3 ++-
sound/soc/rockchip/rockchip_max98090.c | 20
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index b43657e6e655..d610b553ea3b 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -40,9 +40,10 @@ config SND_SOC_ROCKCHIP_MAX98090
select SND_SOC_ROCKCHIP_I2S
select SND_SOC_MAX98090
select SND_SOC_TS3A227E
+ select SND_SOC_HDMI_CODEC
help
Say Y or M here if you want to add support for SoC audio on Rockchip
- boards using the MAX98090 codec, such as Veyron.
+ boards using the MAX98090 codec and HDMI codec, such as Veyron.
config SND_SOC_ROCKCHIP_RT5645
tristate "ASoC support for Rockchip boards using a RT5645/RT5650 codec"
diff --git a/sound/soc/rockchip/rockchip_max98090.c
b/sound/soc/rockchip/rockchip_max98090.c
index c82948e383da..c81c4acda917 100644
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -134,6 +134,25 @@ enum {
DAILINK_HDMI,
};
+static struct snd_soc_jack rk_hdmi_jack;
+
+static int rk_hdmi_init(struct snd_soc_pcm_runtime *runtime)
+{
+ struct snd_soc_card *card = runtime->card;
+ struct snd_soc_component *component = runtime->codec_dai->component;
+ int ret;
+
+ /* enable jack detection */
+ ret = snd_soc_card_jack_new(card, "HDMI Jack", SND_JACK_LINEOUT,
+ &rk_hdmi_jack, NULL, 0);
+ if (ret) {
+ dev_err(card->dev, "Can't new HDMI Jack %d\n", ret);
+ return ret;
+ }
+
+ return hdmi_codec_set_jack_detect(component, &rk_hdmi_jack);
+}
+
/* max98090 and HDMI codec dai_link */
static struct snd_soc_dai_link rk_dailinks[] = {
[DAILINK_MAX98090] = {
@@ -151,6 +170,7 @@ static struct snd_soc_dai_link rk_dailinks[] = {
.ops = &rk_aif1_ops,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
+ .init = rk_hdmi_init,
SND_SOC_DAILINK_REG(hdmi),
}
};
--
2.23.0.237.gc6a4ce50a0-goog
[PATCH v6] dt-bindings: ASoC: Add tas2770 smart PA dt bindings
From: Frank Shi
Add tas2770 smart PA dt bindings
Signed-off-by: Frank Shi
---
.../devicetree/bindings/sound/tas2770.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2770.txt
diff --git a/Documentation/devicetree/bindings/sound/tas2770.txt
b/Documentation/devicetree/bindings/sound/tas2770.txt
new file mode 100644
index 000..ede6bb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2770.txt
@@ -0,0 +1,37 @@
+Texas Instruments TAS2770 Smart PA
+
+The TAS2770 is a mono, digital input Class-D audio amplifier optimized for
+efficiently driving high peak power into small loudspeakers.
+Integrated speaker voltage and current sense provides for
+real time monitoring of loudspeaker behavior.
+
+Required properties:
+
+ - compatible:- Should contain "ti,tas2770".
+ - reg: - The i2c address. Should contain <0x4c>,
<0x4d>,<0x4e>, or <0x4f>.
+ - #address-cells - Should be <1>.
+ - #size-cells - Should be <0>.
+ - ti,asi-format: - Sets TDM RX capture edge. 0->Rising; 1->Falling.
+ - ti,imon-slot-no:- TDM TX current sense time slot.
+ - ti,vmon-slot-no:- TDM TX voltage sense time slot.
+
+Optional properties:
+
+- interrupt-parent: the phandle to the interrupt controller which provides
+ the interrupt.
+- interrupts: interrupt specification for data-ready.
+
+Examples:
+
+tas2770@4c {
+compatible = "ti,tas2770";
+reg = <0x4c>;
+#address-cells = <1>;
+#size-cells = <0>;
+interrupt-parent = <&msm_gpio>;
+interrupts = <97 0>;
+ti,asi-format = <0>;
+ti,imon-slot-no = <0>;
+ti,vmon-slot-no = <2>;
+};
+
--
2.7.4
[PATCH v6] tas2770: add tas2770 smart PA kernel driver
From: Frank Shi
add tas2770 smart PA kernel driver
Signed-off-by: Frank Shi
---
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas2770.c | 814 +
sound/soc/codecs/tas2770.h | 164 +
4 files changed, 985 insertions(+)
create mode 100644 sound/soc/codecs/tas2770.c
create mode 100644 sound/soc/codecs/tas2770.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 8f3e787..cc92da3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -111,6 +111,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_STI_SAS
select SND_SOC_TAS2552 if I2C
+ select SND_SOC_TAS2770 if I2C
select SND_SOC_TAS5086 if I2C
select SND_SOC_TAS571X if I2C
select SND_SOC_TFA9879 if I2C
@@ -652,6 +653,10 @@ config SND_SOC_TAS2552
tristate "Texas Instruments TAS2552 Mono Audio amplifier"
depends on I2C
+config SND_SOC_TAS2770
+ tristate "Texas Instruments TAS2770 speaker amplifier"
+ depends on I2C
+
config SND_SOC_TAS5086
tristate "Texas Instruments TAS5086 speaker amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 5305cc6..63b8488 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -116,6 +116,7 @@ snd-soc-stac9766-objs := stac9766.o
snd-soc-sti-sas-objs := sti-sas.o
snd-soc-tas5086-objs := tas5086.o
snd-soc-tas571x-objs := tas571x.o
+snd-soc-tas2770-objs := tas2770.o
snd-soc-tfa9879-objs := tfa9879.o
snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
@@ -332,6 +333,7 @@ obj-$(CONFIG_SND_SOC_STI_SAS) += snd-soc-sti-sas.o
obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o
obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
+obj-$(CONFIG_SND_SOC_TAS2770) += snd-soc-tas2770.o
obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o
obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o
diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
new file mode 100644
index 000..bd7df2ee
--- /dev/null
+++ b/sound/soc/codecs/tas2770.c
@@ -0,0 +1,814 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// ALSA SoC Texas Instruments TAS2770 20-W Digital Input Mono Class-D
+// Audio Amplifier with Speaker I/V Sense
+//
+// Copyright (C) 2016-2017 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Tracy Yi
+// Frank Shi
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tas2770.h"
+
+#define TAS2770_MDELAY 0xFFFE
+
+static void tas2770_reset(struct tas2770_priv *tas2770)
+{
+ if (tas2770->reset_gpio) {
+ gpiod_set_value_cansleep(tas2770->reset_gpio, 0);
+ msleep(20);
+ gpiod_set_value_cansleep(tas2770->reset_gpio, 1);
+ }
+ snd_soc_component_write(tas2770->component, TAS2770_SW_RST,
+ TAS2770_RST);
+}
+
+static int tas2770_set_bias_level(struct snd_soc_component *component,
+enum snd_soc_bias_level level)
+{
+ struct tas2770_priv *tas2770 =
+ snd_soc_component_get_drvdata(component);
+
+ switch (level) {
+ case SND_SOC_BIAS_ON:
+ snd_soc_component_update_bits(component,
+ TAS2770_PWR_CTRL,
+ TAS2770_PWR_CTRL_MASK,
+ TAS2770_PWR_CTRL_ACTIVE);
+ break;
+
+ case SND_SOC_BIAS_OFF:
+ snd_soc_component_update_bits(component,
+ TAS2770_PWR_CTRL,
+ TAS2770_PWR_CTRL_MASK,
+ TAS2770_PWR_CTRL_SHUTDOWN);
+ break;
+
+ default:
+ dev_err(tas2770->dev,
+ "wrong power level setting %d\n", level);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int tas2770_codec_suspend(struct snd_soc_component *component)
+{
+ int ret;
+
+ ret = snd_soc_component_update_bits(component,
+ TAS2770_PWR_CTRL,
+ TAS2770_PWR_CTRL_MASK,
+ TAS2770_PWR_CTRL_SHUTDOWN);
+ if (ret) {
+ snd_soc_component_update_bits(component,
+ TAS2770_PWR_CTRL,
+ TAS2770_PWR_CTRL_MASK,
+ TAS2770_PWR_CTRL_ACTIVE);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int tas2770_codec_resume(struct snd_soc_component *component)
+{
+ int ret;
+
+ ret = snd_soc_component_update_bits(compo
Re: [RFC PATCH v3 3/6] timekeeping: Expose API allowing retrival of current clocksource and counter value
On 18/09/19 10:07, Jianyong Wu wrote:
> From Marc Zyngier
> A number of PTP drivers (such as ptp-kvm) are assuming what the
> current clock source is, which could lead to interesting effects on
> systems where the clocksource can change depending on external events.
>
> For this purpose, add a new API that retrives both the current
> monotonic clock as well as its counter value.
>
> From Jianyong Wu: export this API then modules can use it.
See review of patch 4. ktime_get_snapshot is even better for your
needs, if I'm not mistaken.
Paolo
> Signed-off-by: Marc Zyngier
> Signed-off-by: Jianyong Wu
> ---
> include/linux/timekeeping.h | 3 +++
> kernel/time/timekeeping.c | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index a8ab0f143ac4..a5389adaa8bc 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -247,6 +247,9 @@ extern int get_device_system_crosststamp(
> struct system_time_snapshot *history,
> struct system_device_crosststamp *xtstamp);
>
> +/* Obtain current monotonic clock and its counter value */
> +extern void get_current_counterval(struct system_counterval_t *sc);
> +
> /*
> * Simultaneously snapshot realtime and monotonic raw clocks
> */
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 44b726bab4bd..07a0969625b1 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1098,6 +1098,19 @@ static bool cycle_between(u64 before, u64 test, u64
> after)
> return false;
> }
>
> +/**
> + * get_current_counterval - Snapshot the current clocksource and counter
> value
> + * @sc: Pointer to a struct containing the current clocksource and its
> value
> + */
> +void get_current_counterval(struct system_counterval_t *sc)
> +{
> + struct timekeeper *tk = &tk_core.timekeeper;
> +
> + sc->cs = READ_ONCE(tk->tkr_mono.clock);
> + sc->cycles = sc->cs->read(sc->cs);
> +}
> +EXPORT_SYMBOL_GPL(get_current_counterval);
> +
> /**
> * get_device_system_crosststamp - Synchronously capture system/device
> timestamp
> * @get_time_fn: Callback to get simultaneous device time and
>
Re: [GIT PULL] LED updates for 5.4-rc1
On Tue, Sep 17, 2019 at 06:13:09PM -0700, Linus Torvalds wrote: > On Mon, Sep 16, 2019 at 3:21 PM Jacek Anaszewski > wrote: > > > > There is one merge of tag with generic_lookup_helpers since > > LED class has been made using class_find_device_by_name() helper: > > > > Merge tag 'generic_lookup_helpers' into for-next > > platform: Add platform_find_device_by_driver() helper > > drivers: Add generic helper to match any device > > drivers: Introduce device lookup variants by ACPI_COMPANION device > > drivers: Introduce device lookup variants by device type > > drivers: Introduce device lookup variants by fwnode > > drivers: Introduce device lookup variants by of_node > > drivers: Introduce device lookup variants by name > > So this is fine and I've pulled it, but I have to say that I > absolutely detest how this device.h header keeps just growing > endlessly: > > [torvalds@linux]$ wc include/linux/device.h >1921 8252 66021 include/linux/device.h > > that's almost 2k of header file, and it's included a _lot_: > > [torvalds@linux]$ git grep include.*linux/device.h | wc >25185085 144875 > > and many of those includes are actually from other core header files, > so it's effectively included from even more trees. > > Yes, yes, many of those 2k lines are comments. But still... Do we > really want to have that humongous 65kB, 2kloc header file, and keep > growing it forever? > > Greg? Yeah, it is getting big, I'll look into splitting it up. thanks, greg k-h > > Linus
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Wed, Sep 18, 2019 at 03:33:04PM +0900, Sergey Senozhatsky wrote: > On (09/18/19 08:16), 'Greg KH' wrote: > [..] > > > Note, that Samsung is still improving sdfat driver. For instance, > > > what will be realeased soon is sdfat v2.3.0, which will include support > > > for "UtcOffset" of "File Directory Entry", in order to satisfy > > > exFAT specification 7.4. > > > [..] > > If Samsung wishes to use their sdfat codebase as the "seed" to work from > > for this, please submit a patch adding the latest version to the kernel > > tree and we can compare and work from there. > > Isn't it what Ju Hyung did? He took sdfat codebase (the most recent > among publicly available) as the seed, cleaned it up a bit and submitted > as a patch. He did? I do not see a patch anywhere, what is the message-id of it? > Well, technically, Valdis did the same, it's just he forked a slightly > more outdated (and not anymore used by Samsung) codebase. He took the "best known at the time" codebase, as we had nothing else to work with. thanks, greg k-h
Re: [PATCH stable 4.4 net] net: rds: Fix NULL ptr use in rds_tcp_kill_sock
On Wed, Sep 18, 2019 at 04:37:33PM +0800, Mao Wenan wrote:
> After the commit c4e97b06cfdc ("net: rds: force to destroy
> connection if t_sock is NULL in rds_tcp_kill_sock()."),
> it introduced null-ptr-deref in rds_tcp_kill_sock as below:
>
> BUG: KASAN: null-ptr-deref on address 0020
> Read of size 8 by task kworker/u16:10/910
> CPU: 3 PID: 910 Comm: kworker/u16:10 Not tainted 4.4.178+ #3
> Hardware name: linux,dummy-virt (DT)
> Workqueue: netns cleanup_net
> Call trace:
> [] dump_backtrace+0x0/0x618
> [] show_stack+0x38/0x60
> [] dump_stack+0x1a8/0x230
> [] kasan_report_error+0xc8c/0xfc0
> [] kasan_report+0x94/0xd8
> [] __asan_load8+0x88/0x150
> [] rds_tcp_dev_event+0x734/0xb48
> [] raw_notifier_call_chain+0x150/0x1e8
> [] call_netdevice_notifiers_info+0x90/0x110
> [] netdev_run_todo+0x2f4/0xb08
> [] rtnl_unlock+0x2c/0x48
> [] default_device_exit_batch+0x444/0x528
> [] ops_exit_list+0x1c0/0x240
> [] cleanup_net+0x738/0xbf8
> [] process_one_work+0x96c/0x13e0
> [] worker_thread+0x7e0/0x1910
> [] kthread+0x304/0x390
> [] ret_from_fork+0x10/0x50
>
> If the first loop add the tc->t_sock = NULL to the tmp_list,
> 1). list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node)
>
> then the second loop is to find connections to destroy, tc->t_sock
> might equal NULL, and tc->t_sock->sk happens null-ptr-deref.
> 2). list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node)
>
> Fixes: c4e97b06cfdc ("net: rds: force to destroy connection if t_sock is NULL
> in rds_tcp_kill_sock().")
> Signed-off-by: Mao Wenan
> ---
> net/rds/tcp.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Why is this not needed upstream as well?
4.9.y? 4.14.y? anything else?
thanks,
greg k-h
[PATCH v2] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
Before commit e42ee61017f5 ("of: Let of_for_each_phandle fallback to
non-negative cell_count") the iterator functions calling
of_for_each_phandle assumed a cell count of 0 if cells_name was NULL.
This corner case was missed when implementing the fallback logic in
e42ee61017f5 and resulted in an endless loop.
Restore the old behaviour of of_count_phandle_with_args() and
of_parse_phandle_with_args() and add a check to
of_phandle_iterator_init() to prevent a similar failure as a safety
precaution. of_parse_phandle_with_args_map() doesn't need a similar fix
as cells_name isn't NULL there.
Affected drivers are:
- drivers/base/power/domain.c
- drivers/base/power/domain.c
- drivers/clk/ti/clk-dra7-atl.c
- drivers/hwmon/ibmpowernv.c
- drivers/i2c/muxes/i2c-demux-pinctrl.c
- drivers/iommu/mtk_iommu.c
- drivers/net/ethernet/freescale/fman/mac.c
- drivers/opp/of.c
- drivers/perf/arm_dsu_pmu.c
- drivers/regulator/of_regulator.c
- drivers/remoteproc/imx_rproc.c
- drivers/soc/rockchip/pm_domains.c
- sound/soc/fsl/imx-audmix.c
- sound/soc/fsl/imx-audmix.c
- sound/soc/meson/axg-card.c
- sound/soc/samsung/tm2_wm5110.c
- sound/soc/samsung/tm2_wm5110.c
Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for
helping pinpoint the actual problem and the testers for confirming this
fix.
Fixes: e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative
cell_count")
Tested-by: Marek Szyprowski
Tested-by: Geert Uytterhoeven
Signed-off-by: Uwe Kleine-König
---
On Wed, Sep 18, 2019 at 08:01:05AM +, Peter Rosin wrote:
> On 2019-09-18 08:38, Uwe Kleine-König wrote:
> > EXPORT_SYMBOL(of_parse_phandle_with_args);
> >
> > @@ -1765,6 +1779,18 @@ int of_count_phandle_with_args(const struct
> > device_node *np, const char *list_na
> > struct of_phandle_iterator it;
> > int rc, cur_index = 0;
> >
> > + /* If cells_name is NULL we assume a cell count of 0 */
> > + if (cells_name == NULL) {
>
> A couple of nits.
>
> I don't know if there are other considerations, but in the previous two
> hunks you use !cells_name instead of comparing explicitly with NULL.
> Personally, I find the shorter form more readable, and in the name of
> consistency bla bla...
Ack, changed to !cells_name here, too.
>
> Also, the comment explaining this NULL-check didn't really make sense
> to me until I realized that knowing the cell count to be zero makes
> counting trivial. Something along those lines should perhaps be in the
> comment?
You're right, I extended the comment a bit.
> But as I said, these are nits. Feel free to ignore.
I considered resending already anyhow as I fatfingerd my email address.
this is fixed now, too. Additionally I fixed a typo in one of the
comments.
Thanks for your feedback.
Best regards
Uwe
drivers/of/base.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2f25d2dfecfa..1d667eb730e1 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1286,6 +1286,13 @@ int of_phandle_iterator_init(struct of_phandle_iterator
*it,
memset(it, 0, sizeof(*it));
+ /*
+* one of cell_count or cells_name must be provided to determine the
+* argument length.
+*/
+ if (cell_count < 0 && !cells_name)
+ return -EINVAL;
+
list = of_get_property(np, list_name, &size);
if (!list)
return -ENOENT;
@@ -1512,10 +1519,17 @@ int of_parse_phandle_with_args(const struct device_node
*np, const char *list_na
const char *cells_name, int index,
struct of_phandle_args *out_args)
{
+ int cell_count = -1;
+
if (index < 0)
return -EINVAL;
- return __of_parse_phandle_with_args(np, list_name, cells_name, -1,
- index, out_args);
+
+ /* If cells_name is NULL we assume a cell count of 0 */
+ if (!cells_name)
+ cell_count = 0;
+
+ return __of_parse_phandle_with_args(np, list_name, cells_name,
+ cell_count, index, out_args);
}
EXPORT_SYMBOL(of_parse_phandle_with_args);
@@ -1765,6 +1779,23 @@ int of_count_phandle_with_args(const struct device_node
*np, const char *list_na
struct of_phandle_iterator it;
int rc, cur_index = 0;
+ /*
+* If cells_name is NULL we assume a cell count of 0. This makes
+* counting the phandles trivial as each 32bit word in the list is a
+* phandle and no arguments are to consider. So we don't iterate through
+* the list but just use the length to determine the phandle count.
+*/
+ if (!cells_name) {
+ const __be32 *list;
+ int size;
+
+ list = of_get_property(np, list_name, &size);
+ if (!list)
+ return -ENOENT;
+
+
[PATCH 1/4] seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW
This allows the seccomp notifier to continue a syscall. A positive
discussion about this feature was triggered by a post to the
ksummit-discuss mailing list (cf. [3]) and took place during KSummit
(cf. [1]) and again at the containers/checkpoint-restore
micro-conference at Linux Plumbers.
Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
which enables a process (watchee) to retrieve an fd for its seccomp
filter. This fd can then be handed to another (usually more privileged)
process (watcher). The watcher will then be able to receive seccomp
messages about the syscalls having been performed by the watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers.
The mknod() syscall can be easily filtered based on dev_t. This allows
us to only intercept a very specific subset of mknod() syscalls.
Furthermore, mknod() is not possible in user namespaces toto coelo and
so intercepting and denying syscalls that are not in the whitelist on
accident is not a big deal. The watchee won't notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g.
setxattr()) cannot be easily filtered like mknod() because they have
pointer arguments. Additionally, some of them might actually succeed in
user namespaces (e.g. setxattr() for all "user.*" xattrs). Since we
currently cannot tell seccomp to continue from a user notifier we are
stuck with performing all of the syscalls in lieu of the container. This
is a huge security liability since it is extremely difficult to
correctly assume all of the necessary privileges of the calling task
such that the syscall can be successfully emulated without escaping
other additional security restrictions (think missing CAP_MKNOD for
mknod(), or MS_NODEV on a filesystem etc.). This can be solved by
telling seccomp to resume the syscall.
One thing that came up in the discussion was the problem that another
thread could change the memory after userspace has decided to let the
syscall continue which is a well known TOCTOU with seccomp which is
present in other ways already.
The discussion showed that this feature is already very useful for any
syscall without pointer arguments. For any accidentally intercepted
non-pointer syscall it is safe to continue.
For syscalls with pointer arguments there is a race but for any cautious
userspace and the main usec cases the race doesn't matter. The notifier
is intended to be used in a scenario where a more privileged watcher
supervises the syscalls of lesser privileged watchee to allow it to get
around kernel-enforced limitations by performing the syscall for it
whenever deemed save by the watcher. Hence, if a user tricks the watcher
into allowing a syscall they will either get a deny based on
kernel-enforced restrictions later or they will have changed the
arguments in such a way that they manage to perform a syscall with
arguments that they would've been allowed to do anyway.
In general, it is good to point out again, that the notifier fd was not
intended to allow userspace to implement a security policy but rather to
work around kernel security mechanisms in cases where the watcher knows
that a given action is safe to perform.
/* References */
[1]: https://linuxplumbersconf.org/event/4/contributions/560
[2]: https://linuxplumbersconf.org/event/4/contributions/477
[3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io
[4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Christian Brauner
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Tycho Andersen
CC: Tyler Hicks
Cc: Jann Horn
---
include/uapi/linux/seccomp.h | 2 ++
kernel/seccomp.c | 24
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 90734aa5aa36..2c23b9aa6383 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -76,6 +76,8 @@ struct seccomp_notif {
struct seccomp_data data;
};
+#define SECCOMP_RET_USER_NOTIF_ALLOW 0x0001
+
struct seccomp_notif_resp {
__u64 id;
__s64 val;
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index dba52a7db5e8..cdb90184d6d7 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -75,6 +75,7 @@ struct seccomp_knotif {
/* The return values, only valid when in SECCOMP_NOTIFY_REPLIED */
int error;
long val;
+ u32 flags;
/* Signals when this has entered SECCOMP_NOTIFY_REPLIED */
struct completion ready;
@@ -732,11 +733,12 @@ static u64 seccomp_next_notify_id(struct seccomp_filter
*filter)
return filter->notif->next_id++;
}
-static void seccomp_do_user_notification(int this_syscall,
+static bool seccomp_do_user_notification(int this_syscall,
struct seccomp_filter *match,
[PATCH 2/4] seccomp: add two missing ptrace ifdefines
Add tw missing ptrace ifdefines to avoid compilation errors on systems
that do not provide PTRACE_EVENTMSG_SYSCALL_ENTRY or
PTRACE_EVENTMSG_SYSCALL_EXIT or:
gcc -Wl,-no-as-needed -Wall seccomp_bpf.c -lpthread -o seccomp_bpf
In file included from seccomp_bpf.c:52:0:
seccomp_bpf.c: In function ‘tracer_ptrace’:
seccomp_bpf.c:1792:20: error: ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’ undeclared (first
use in this function); did you mean ‘PTRACE_EVENT_CLONE’?
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^
seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^
seccomp_bpf.c:1792:20: note: each undeclared identifier is reported only once
for each function it appears in
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^
seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^
seccomp_bpf.c:1793:6: error: ‘PTRACE_EVENTMSG_SYSCALL_EXIT’ undeclared (first
use in this function); did you mean ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’?
: PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
^
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^
seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^
Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Christian Brauner
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Shuah Khan
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: Tycho Andersen
CC: Tyler Hicks
Cc: Jann Horn
Cc: sta...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 6ef7f16c4cf5..ee52eab01800 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -155,6 +155,14 @@ struct seccomp_data {
#ifndef PTRACE_SECCOMP_GET_METADATA
#define PTRACE_SECCOMP_GET_METADATA0x420d
+#ifndef PTRACE_EVENTMSG_SYSCALL_ENTRY
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 1
+#endif
+
+#ifndef PTRACE_EVENTMSG_SYSCALL_EXIT
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 2
+#endif
+
struct seccomp_metadata {
__u64 filter_off; /* Input: which filter */
__u64 flags; /* Output: filter's flags */
--
2.23.0
[PATCH 4/4] seccomp: test SECCOMP_RET_USER_NOTIF_ALLOW
Test whether a syscall can be performed after having been intercepted by
the seccomp notifier. The test uses dup() and kcmp() since it allows us to
nicely test whether the dup() syscall actually succeeded by comparing whether
the fd refers to the same underlying struct file.
Signed-off-by: Christian Brauner
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Shuah Khan
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: Tycho Andersen
CC: Tyler Hicks
Cc: Jann Horn
Cc: sta...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 99 +++
1 file changed, 99 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 921f0e26f835..788d7e9007d5 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -175,6 +176,10 @@ struct seccomp_metadata {
#define SECCOMP_RET_USER_NOTIF 0x7fc0U
+#ifndef SECCOMP_RET_USER_NOTIF_ALLOW
+#define SECCOMP_RET_USER_NOTIF_ALLOW 0x0001
+#endif
+
#define SECCOMP_IOC_MAGIC '!'
#define SECCOMP_IO(nr) _IO(SECCOMP_IOC_MAGIC, nr)
#define SECCOMP_IOR(nr, type) _IOR(SECCOMP_IOC_MAGIC, nr, type)
@@ -3489,6 +3494,100 @@ TEST(seccomp_get_notif_sizes)
EXPECT_EQ(sizes.seccomp_notif_resp, sizeof(struct seccomp_notif_resp));
}
+static int filecmp(pid_t pid1, pid_t pid2, int fd1, int fd2)
+{
+#ifdef __NR_kcmp
+ return syscall(__NR_kcmp, pid1, pid2, KCMP_FILE, fd1, fd2);
+#else
+ errno = ENOSYS;
+ return -1;
+#endif
+}
+
+TEST(user_notification_continue)
+{
+ pid_t pid;
+ long ret;
+ int status, listener;
+ struct seccomp_notif req = {};
+ struct seccomp_notif_resp resp = {};
+ struct pollfd pollfd;
+
+ ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+ ASSERT_EQ(0, ret) {
+ TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
+ }
+
+ listener = user_trap_syscall(__NR_dup,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
+ ASSERT_GE(listener, 0);
+
+ pid = fork();
+ ASSERT_GE(pid, 0);
+
+ if (pid == 0) {
+ int dup_fd, pipe_fds[2];
+ pid_t self;
+
+ ret = pipe(pipe_fds);
+ if (ret < 0)
+ exit(EXIT_FAILURE);
+
+ dup_fd = dup(pipe_fds[0]);
+ if (dup_fd < 0)
+ exit(EXIT_FAILURE);
+
+ self = getpid();
+
+ ret = filecmp(self, self, pipe_fds[0], dup_fd);
+ if (ret)
+ exit(EXIT_FAILURE);
+
+ exit(EXIT_SUCCESS);
+ }
+
+ pollfd.fd = listener;
+ pollfd.events = POLLIN | POLLOUT;
+
+ EXPECT_GT(poll(&pollfd, 1, -1), 0);
+ EXPECT_EQ(pollfd.revents, POLLIN);
+
+ EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_RECV, &req), 0);
+
+ pollfd.fd = listener;
+ pollfd.events = POLLIN | POLLOUT;
+
+ EXPECT_GT(poll(&pollfd, 1, -1), 0);
+ EXPECT_EQ(pollfd.revents, POLLOUT);
+
+ EXPECT_EQ(req.data.nr, __NR_dup);
+
+ resp.id = req.id;
+ resp.flags = SECCOMP_RET_USER_NOTIF_ALLOW;
+
+ /* check that if (flags & SECCOMP_RET_USER_NOTIF_ALLOW) the rest is 0 */
+ resp.error = 0;
+ resp.val = USER_NOTIF_MAGIC;
+ EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), -1);
+ EXPECT_EQ(errno, EINVAL);
+
+ resp.error = USER_NOTIF_MAGIC;
+ resp.val = 0;
+ EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), -1);
+ EXPECT_EQ(errno, EINVAL);
+
+ resp.error = 0;
+ resp.val = 0;
+ EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0) {
+ if (errno == EINVAL)
+ XFAIL(goto skip, "Kernel does not support
SECCOMP_RET_USER_NOTIF_ALLOW");
+ }
+
+skip:
+ EXPECT_EQ(waitpid(pid, &status, 0), pid);
+ EXPECT_EQ(true, WIFEXITED(status));
+ EXPECT_EQ(0, WEXITSTATUS(status));
+}
+
/*
* TODO:
* - add microbenchmarks
--
2.23.0
[PATCH 0/4] seccomp: continue syscall from notifier
Hey everyone, This is the patchset coming out of the KSummit session Kees and I gave in Lisbon last week (cf. [3] which also contains slides with more details on related things such as deep argument inspection). The simple idea is to extend the seccomp notifier to allow for the continuation of a syscall. The rationale for this can be found in the commit message to [1]. For the curious there is more detail in [2]. This patchset would unblock supervising an extended set of syscalls such as mount() where a privileged process is supervising the syscalls of a lesser privileged process and emulates the syscall for the latter in userspace. For more comments on security see [1]. Thanks! Christian /* References */ [1]: [PATCH 1/4] seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW [2]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io [3]: https://linuxplumbersconf.org/event/4/contributions/560 Christian Brauner (4): seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW seccomp: add two missing ptrace ifdefines seccomp: avoid overflow in implicit constant conversion seccomp: test SECCOMP_RET_USER_NOTIF_ALLOW include/uapi/linux/seccomp.h | 2 + kernel/seccomp.c | 24 +++- tools/testing/selftests/seccomp/seccomp_bpf.c | 110 +- 3 files changed, 131 insertions(+), 5 deletions(-) -- 2.23.0
[PATCH 3/4] seccomp: avoid overflow in implicit constant conversion
USER_NOTIF_MAGIC is assigned to int variables in this test so set it to INT_MAX
to avoid warnings:
seccomp_bpf.c: In function ‘user_notification_continue’:
seccomp_bpf.c:3088:26: warning: overflow in implicit constant conversion
[-Woverflow]
#define USER_NOTIF_MAGIC 116983961184613L
^
seccomp_bpf.c:3572:15: note: in expansion of macro ‘USER_NOTIF_MAGIC’
resp.error = USER_NOTIF_MAGIC;
^~~~
Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Christian Brauner
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Shuah Khan
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: Tycho Andersen
CC: Tyler Hicks
Cc: Jann Horn
Cc: sta...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index ee52eab01800..921f0e26f835 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3080,7 +3081,7 @@ static int user_trap_syscall(int nr, unsigned int flags)
return seccomp(SECCOMP_SET_MODE_FILTER, flags, &prog);
}
-#define USER_NOTIF_MAGIC 116983961184613L
+#define USER_NOTIF_MAGIC INT_MAX
TEST(user_notification_basic)
{
pid_t pid;
--
2.23.0
Re: [PATCH v2 1/7] counter: Simplify the count_read and count_write callbacks
Le mer. 18 sept. 2019 à 09:53, William Breathitt Gray
a écrit :
>
> The count_read and count_write callbacks are simplified to pass val as
> unsigned long rather than as an opaque data structure. The opaque
> counter_count_read_value and counter_count_write_value structures,
> counter_count_value_type enum, and relevant counter_count_read_value_set
> and counter_count_write_value_get functions, are removed as they are no
> longer used.
>
> Signed-off-by: William Breathitt Gray
Hi William,
This first patch break the compilation because you remove some
structure needed for the drivers.
You should merge all the serie in 1 patch to avoid that.
Benjamin
> ---
> drivers/counter/counter.c | 66 +--
> include/linux/counter.h | 43 +++--
> 2 files changed, 12 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
> index 106bc7180cd8..1d08f1437b1b 100644
> --- a/drivers/counter/counter.c
> +++ b/drivers/counter/counter.c
> @@ -246,60 +246,6 @@ void counter_signal_read_value_set(struct
> counter_signal_read_value *const val,
> }
> EXPORT_SYMBOL_GPL(counter_signal_read_value_set);
>
> -/**
> - * counter_count_read_value_set - set counter_count_read_value data
> - * @val: counter_count_read_value structure to set
> - * @type: property Count data represents
> - * @data: Count data
> - *
> - * This function sets an opaque counter_count_read_value structure with the
> - * provided Count data.
> - */
> -void counter_count_read_value_set(struct counter_count_read_value *const val,
> - const enum counter_count_value_type type,
> - void *const data)
> -{
> - switch (type) {
> - case COUNTER_COUNT_POSITION:
> - val->len = sprintf(val->buf, "%lu\n", *(unsigned long *)data);
> - break;
> - default:
> - val->len = 0;
> - }
> -}
> -EXPORT_SYMBOL_GPL(counter_count_read_value_set);
> -
> -/**
> - * counter_count_write_value_get - get counter_count_write_value data
> - * @data: Count data
> - * @type: property Count data represents
> - * @val: counter_count_write_value structure containing data
> - *
> - * This function extracts Count data from the provided opaque
> - * counter_count_write_value structure and stores it at the address provided
> by
> - * @data.
> - *
> - * RETURNS:
> - * 0 on success, negative error number on failure.
> - */
> -int counter_count_write_value_get(void *const data,
> - const enum counter_count_value_type type,
> - const struct counter_count_write_value
> *const val)
> -{
> - int err;
> -
> - switch (type) {
> - case COUNTER_COUNT_POSITION:
> - err = kstrtoul(val->buf, 0, data);
> - if (err)
> - return err;
> - break;
> - }
> -
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(counter_count_write_value_get);
> -
> struct counter_attr_parm {
> struct counter_device_attr_group *group;
> const char *prefix;
> @@ -788,13 +734,13 @@ static ssize_t counter_count_show(struct device *dev,
> const struct counter_count_unit *const component = devattr->component;
> struct counter_count *const count = component->count;
> int err;
> - struct counter_count_read_value val = { .buf = buf };
> + unsigned long val;
>
> err = counter->ops->count_read(counter, count, &val);
> if (err)
> return err;
>
> - return val.len;
> + return sprintf(buf, "%lu\n", val);
> }
>
> static ssize_t counter_count_store(struct device *dev,
> @@ -806,9 +752,13 @@ static ssize_t counter_count_store(struct device *dev,
> const struct counter_count_unit *const component = devattr->component;
> struct counter_count *const count = component->count;
> int err;
> - struct counter_count_write_value val = { .buf = buf };
> + unsigned long val;
> +
> + err = kstrtoul(buf, 0, &val);
> + if (err)
> + return err;
>
> - err = counter->ops->count_write(counter, count, &val);
> + err = counter->ops->count_write(counter, count, val);
> if (err)
> return err;
>
> diff --git a/include/linux/counter.h b/include/linux/counter.h
> index a061cdcdef7c..7e40796598a6 100644
> --- a/include/linux/counter.h
> +++ b/include/linux/counter.h
> @@ -300,24 +300,6 @@ struct counter_signal_read_value {
> size_t len;
> };
>
> -/**
> - * struct counter_count_read_value - Opaque Count read value
> - * @buf: string representation of Count read value
> - * @len: length of string in @buf
> - */
> -struct counter_count_read_value {
> - char *buf;
> - size_t len;
> -};
> -
> -/**
> - * struct counter_count_write_value - Opaque Count write val
Re: [PATCH] staging: exfat: add exfat filesystem code to
On (09/18/19 10:26), 'Greg KH' wrote: > On Wed, Sep 18, 2019 at 03:33:04PM +0900, Sergey Senozhatsky wrote: > > On (09/18/19 08:16), 'Greg KH' wrote: > > [..] > > > > Note, that Samsung is still improving sdfat driver. For instance, > > > > what will be realeased soon is sdfat v2.3.0, which will include support > > > > for "UtcOffset" of "File Directory Entry", in order to satisfy > > > > exFAT specification 7.4. > > > > > [..] > > > If Samsung wishes to use their sdfat codebase as the "seed" to work from > > > for this, please submit a patch adding the latest version to the kernel > > > tree and we can compare and work from there. > > > > Isn't it what Ju Hyung did? He took sdfat codebase (the most recent > > among publicly available) as the seed, cleaned it up a bit and submitted > > as a patch. > > He did? I do not see a patch anywhere, what is the message-id of it? Sorry. No, he did not. I somehow thought that he did, but it seems that I just looked at his github and emails. > > Well, technically, Valdis did the same, it's just he forked a slightly > > more outdated (and not anymore used by Samsung) codebase. > > He took the "best known at the time" codebase, as we had nothing else to > work with. Well, then Valdis probably took it a long long time ago. Current "best known" is v2.2, publicly available under GPLv2 at opensource.samsung.com -ss
RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Jassi, > Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the > ARM SMC/HVC mailbox > > On Tue, Sep 17, 2019 at 12:31 PM Andre Przywara > wrote: > > > > On Mon, 16 Sep 2019 09:44:37 + > > Peng Fan wrote: > > > > Hi, > > > > > From: Peng Fan > > > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > > trigger actions in software layers running in the EL2 or EL3 exception > levels. > > > The term "ARM" here relates to the SMC instruction as part of the > > > ARM instruction set, not as a standard endorsed by ARM Ltd. > > > > > > Signed-off-by: Peng Fan > > > --- > > > .../devicetree/bindings/mailbox/arm-smc.yaml | 96 > ++ > > > 1 file changed, 96 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > new file mode 100644 > > > index ..bf01bec035fc > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > @@ -0,0 +1,96 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > > +--- > > > +$id: > > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde > > > > +vicetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02% > 7C01 > > > > +%7Cpeng.fan%40nxp.com%7Cf8065d24dd474238baf008d73bf8dc7a%7C686 > ea1d3 > > > > +bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637043812342903260&sd > ata=vC3 > > > > +S8hvYDxDhNbIQoC44hpO5bw1yYZdBwu%2B%2Fp8mV0hI%3D&reserv > ed=0 > > > +$schema: > > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde > > > > +vicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7C > peng. > > > > +fan%40nxp.com%7Cf8065d24dd474238baf008d73bf8dc7a%7C686ea1d3bc2 > b4c6f > > > > +a92cd99c5c301635%7C0%7C1%7C637043812342903260&sdata=IDHd > vf1Mgw1 > > > +BR%2Bo4XJ%2BjQS%2Bx1pSBzADnW44B2hZLzKw%3D&reserved=0 > > > + > > > +title: ARM SMC Mailbox Interface > > > + > > > +maintainers: > > > + - Peng Fan > > > + > > > +description: | > > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > > +(hypervisor > > > > I think "or" instead of "and" is less confusing. > > > > > + call) instruction to trigger a mailbox-connected activity in > > > + firmware, executing on the very same core as the caller. The > > > + value of r0/w0/x0 the firmware returns after the smc call is > > > + delivered as a received message to the mailbox framework, so > > > + synchronous communication can be established. The exact meaning > > > + of the action the mailbox triggers as well as the return value is > > > + defined by their users and is not subject to this binding. > > > + > > > + One use case of this mailbox is the SCMI interface, which uses > > > + shared > > > > One example use case of this mailbox ... > > (to make it more obvious that it's not restricted to this) > > > > > + memory to transfer commands and parameters, and a mailbox to > > > + trigger a function call. This allows SoCs without a separate > > > + management processor (or when such a processor is not available > > > + or used) to use this standardized interface anyway. > > > + > > > + This binding describes no hardware, but establishes a firmware > interface. > > > + Upon receiving an SMC using one of the described SMC function > > > + identifiers, > > > > ... the described SMC function > > identifier, > > > > > + the firmware is expected to trigger some mailbox connected > functionality. > > > + The communication follows the ARM SMC calling convention. > > > + Firmware expects an SMC function identifier in r0 or w0. The > > > + supported identifiers are passed from consumers, > > > > identifier > > > > "passed from consumers": How? Where? > > But I want to repeat: We should not allow this. > > This is a binding for a mailbox controller driver, not a generic firmware > backdoor. > > > Exactly. The mailbox controller here is the SMC/HVC instruction, which > needs 9 arguments to work. The fact that the fist argument is always going to > be same on a platform is just the way we use this instruction. > > > We should be as strict as possible to avoid any security issues. > > > Any example of such a security issue? > > > The firmware certainly knows the function ID it implements. The firmware > controls the DT. So it is straight-forward to put the ID into the DT. The > firmware could even do this at boot time, dynamically, before passing on the > DT to the non-secure world (bootloader or kernel). > > > > What would be the use case of this functionality? > > > At least for flexibility and consistency. > > > > or listed in the the arm,func-ids > > > >arm,func-id > > > > > + properties as described below. The firmware can return one value > > > + in > > > > property > > > > > + the first SMC resu
RE: [PATCH 3/3] x86/split_lock: Align the x86_capability array to size of unsigned long
From: Luck, Tony > Sent: 17 September 2019 20:14 > On Tue, Sep 17, 2019 at 08:29:28AM +, David Laight wrote: > > From: Tony Luck > > > Sent: 16 September 2019 23:40 > > > From: Fenghua Yu > > > > > > The x86_capability array in cpuinfo_x86 is defined as u32 and thus is > > > naturally aligned to 4 bytes. But, set_bit() and clear_bit() require > > > the array to be aligned to size of unsigned long (i.e. 8 bytes in > > > 64-bit). > > > > > > To fix the alignment issue, align the x86_capability array to size of > > > unsigned long by using unnamed union and 'unsigned long array_align' > > > to force the alignment. > > > > > > Changing the x86_capability array's type to unsigned long may also fix > > > the issue because the x86_capability array will be naturally aligned > > > to size of unsigned long. But this needs additional code changes. > > > So choose the simpler solution by setting the array's alignment to size > > > of unsigned long. > > > > > > Suggested-by: David Laight > > > > While this is probably the only play where this 'capabilities' array > > has been detected as misaligned, ISTR there are several other places > > where the identical array is defined and used. > > These all need fixing as well. > > Agree 100% These three patches cover the places *detected* so > far. For bisectability reasons they need to be upstream before > the patches that add WARN_ON, or the one that turns on alignment > traps. As we find other places, we can fix alignments in other > structures too. > > If you remember what those other places are, please let us know > so we can push patches to fix those. > > If you have a better strategy to find them ... that also would > be very interesting. ISTR doing the following: 1) Looking at the other places where the x86 capabilities got stored. 2) Searching for casts of the bit functions. Try: grep -r --include '*.[ch]' '_bit([^(]*, *([^)]*\*)' . David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH 0/3] tracing/probe: Fix some issues on multiprobe support
Hi Steve, Here are the patches to fix some issues on multiprobe support (and add a testcase for the fix) [1/3] Fix to allow user to enable probe events on unloaded modules. This was supported before multiprobe support. Fix it. [2/3] Reject exactly same probe event. Multiprobe accepts the exact same probe as existing one, but it is meansingless and confusing. Reject the probe events which has exact same probe point and same arguments. [3/3] Add a testcase for [2/3]. Thank you, --- Masami Hiramatsu (3): tracing/probe: Fix to allow user to enable events on unloaded modules tracing/probe: Reject exactly same probe event selftests/ftrace: Update kprobe event error testcase kernel/trace/trace_kprobe.c| 69 ++-- kernel/trace/trace_probe.h |3 + kernel/trace/trace_uprobe.c| 52 +-- .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc |1 4 files changed, 96 insertions(+), 29 deletions(-) -- Masami Hiramatsu
[PATCH 1/3] tracing/probe: Fix to allow user to enable events on unloaded modules
Fix to allow user to enable probe events on unloaded modules.
This operations was allowed before commit 60d53e2c3b75 ("tracing/probe:
Split trace_event related data from trace_probe"), because if users
need to probe module init functions, they have to enable those probe
events before loading module.
Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from
trace_probe")
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7579c53bb053..0ba3239c0270 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -371,31 +371,24 @@ static int enable_trace_kprobe(struct trace_event_call
*call,
if (enabled)
return 0;
- enabled = false;
list_for_each_entry(pos, trace_probe_probe_list(tp), list) {
tk = container_of(pos, struct trace_kprobe, tp);
if (trace_kprobe_has_gone(tk))
continue;
ret = __enable_trace_kprobe(tk);
- if (ret) {
- if (enabled) {
- __disable_trace_kprobe(tp);
- enabled = false;
- }
+ if (ret)
break;
- }
enabled = true;
}
- if (!enabled) {
- /* No probe is enabled. Roll back */
+ if (ret) {
+ /* Failed to enable one of them. Roll back all */
+ if (enabled)
+ __disable_trace_kprobe(tp);
if (file)
trace_probe_remove_file(tp, file);
else
trace_probe_clear_flag(tp, TP_FLAG_PROFILE);
- if (!ret)
- /* Since all probes are gone, this is not available */
- ret = -EADDRNOTAVAIL;
}
return ret;
[PATCH 3/3] selftests/ftrace: Update kprobe event error testcase
Update kprobe event error testcase to test if it correctly finds the exact same probe event. Signed-off-by: Masami Hiramatsu --- .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc |1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc index 39ef7ac1f51c..8a4025e912cb 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc @@ -95,6 +95,7 @@ echo 'p:kprobes/testevent _do_fork abcd=\1' > kprobe_events check_error 'p:kprobes/testevent _do_fork ^bcd=\1' # DIFF_ARG_TYPE check_error 'p:kprobes/testevent _do_fork ^abcd=\1:u8' # DIFF_ARG_TYPE check_error 'p:kprobes/testevent _do_fork ^abcd=\"foo"'# DIFF_ARG_TYPE +check_error '^p:kprobes/testevent _do_fork'# SAME_PROBE fi exit 0
[PATCH] leds-bcm63xx: Use devm_platform_ioremap_resource() in two functions
From: Markus Elfring Date: Wed, 18 Sep 2019 10:45:24 +0200 Simplify these function implementations by using a known function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/leds/leds-bcm6328.c | 7 +-- drivers/leds/leds-bcm6358.c | 7 +-- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c index c50d34e2b098..42e1b7598c3a 100644 --- a/drivers/leds/leds-bcm6328.c +++ b/drivers/leds/leds-bcm6328.c @@ -346,16 +346,11 @@ static int bcm6328_leds_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct device_node *np = pdev->dev.of_node; struct device_node *child; - struct resource *mem_r; void __iomem *mem; spinlock_t *lock; /* memory lock */ unsigned long val, *blink_leds, *blink_delay; - mem_r = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem_r) - return -EINVAL; - - mem = devm_ioremap_resource(dev, mem_r); + mem = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(mem)) return PTR_ERR(mem); diff --git a/drivers/leds/leds-bcm6358.c b/drivers/leds/leds-bcm6358.c index aec285fd21c0..94fefd456ba0 100644 --- a/drivers/leds/leds-bcm6358.c +++ b/drivers/leds/leds-bcm6358.c @@ -151,17 +151,12 @@ static int bcm6358_leds_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct device_node *np = pdev->dev.of_node; struct device_node *child; - struct resource *mem_r; void __iomem *mem; spinlock_t *lock; /* memory lock */ unsigned long val; u32 clk_div; - mem_r = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem_r) - return -EINVAL; - - mem = devm_ioremap_resource(dev, mem_r); + mem = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(mem)) return PTR_ERR(mem); -- 2.23.0
[PATCH 2/3] tracing/probe: Reject exactly same probe event
Reject exactly same probe events as existing probes.
Multiprobe allows user to define multiple probes on same
event. If user appends a probe which exactly same definition
(same probe address and same arguments) on existing event,
the event will record same probe information twice.
That can be confusing users, so reject it.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 52 ---
kernel/trace/trace_probe.h |3 ++
kernel/trace/trace_uprobe.c | 52 ---
3 files changed, 90 insertions(+), 17 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 0ba3239c0270..a6697e28ddda 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -528,10 +528,53 @@ static int unregister_trace_kprobe(struct trace_kprobe
*tk)
return 0;
}
+static bool trace_kprobe_has_same_kprobe(struct trace_kprobe *orig,
+struct trace_kprobe *comp)
+{
+ struct trace_probe_event *tpe = orig->tp.event;
+ struct trace_probe *pos;
+ int i;
+
+ list_for_each_entry(pos, &tpe->probes, list) {
+ orig = container_of(pos, struct trace_kprobe, tp);
+ if (strcmp(trace_kprobe_symbol(orig),
+ trace_kprobe_symbol(comp)) ||
+ trace_kprobe_offset(orig) != trace_kprobe_offset(comp))
+ continue;
+
+ /*
+* trace_probe_compare_arg_type() ensured that nr_args and
+* each argument name and type are same. Let's compare comm.
+*/
+ for (i = 0; i < orig->tp.nr_args; i++) {
+ if (strcmp(orig->tp.args[i].comm,
+ comp->tp.args[i].comm))
+ continue;
+ }
+
+ return true;
+ }
+
+ return false;
+}
+
static int append_trace_kprobe(struct trace_kprobe *tk, struct trace_kprobe
*to)
{
int ret;
+ ret = trace_probe_compare_arg_type(&tk->tp, &to->tp);
+ if (ret) {
+ /* Note that argument starts index = 2 */
+ trace_probe_log_set_index(ret + 1);
+ trace_probe_log_err(0, DIFF_ARG_TYPE);
+ return -EEXIST;
+ }
+ if (trace_kprobe_has_same_kprobe(to, tk)) {
+ trace_probe_log_set_index(0);
+ trace_probe_log_err(0, SAME_PROBE);
+ return -EEXIST;
+ }
+
/* Append to existing event */
ret = trace_probe_append(&tk->tp, &to->tp);
if (ret)
@@ -568,14 +611,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
trace_probe_log_err(0, DIFF_PROBE_TYPE);
ret = -EEXIST;
} else {
- ret = trace_probe_compare_arg_type(&tk->tp,
&old_tk->tp);
- if (ret) {
- /* Note that argument starts index = 2 */
- trace_probe_log_set_index(ret + 1);
- trace_probe_log_err(0, DIFF_ARG_TYPE);
- ret = -EEXIST;
- } else
- ret = append_trace_kprobe(tk, old_tk);
+ ret = append_trace_kprobe(tk, old_tk);
}
goto end;
}
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index f805cc4cbe7c..4ee703728aec 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -436,7 +436,8 @@ extern int traceprobe_define_arg_fields(struct
trace_event_call *event_call,
C(BAD_INSN_BNDRY, "Probe point is not an instruction boundary"),\
C(FAIL_REG_PROBE, "Failed to register probe event"),\
C(DIFF_PROBE_TYPE, "Probe type is different from existing probe"),\
- C(DIFF_ARG_TYPE,"Argument type or name is different from
existing probe"),
+ C(DIFF_ARG_TYPE,"Argument type or name is different from
existing probe"),\
+ C(SAME_PROBE, "There is already the exact same probe event"),
#undef C
#define C(a, b)TP_ERR_##a
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index cbf4da4bf367..34dd6d0016a3 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -410,10 +410,53 @@ static int unregister_trace_uprobe(struct trace_uprobe
*tu)
return 0;
}
+static bool trace_uprobe_has_same_uprobe(struct trace_uprobe *orig,
+struct trace_uprobe *comp)
+{
+ struct trace_probe_event *tpe = orig->tp.event;
+ struct trace_probe *pos;
+ struct inode *comp_inode = d_real_inode(comp->path.dentry);
+ int i;
+
+ list_for_each_entry(pos, &tpe->probes, list) {
+ orig = container_of(
[PATCH] Bluetooth: btrtl: Fix an issue for the incorrect error return code.
From: Max Chou
It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will
return the negative value during errors.
Signed-off-by: Max Chou
---
drivers/bluetooth/btrtl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index bf3c02be6930..ae9a2047f242 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -418,7 +418,7 @@ static int rtl_download_firmware(struct hci_dev *hdev,
if (IS_ERR(skb)) {
rtl_dev_err(hdev, "download fw command failed (%ld)",
PTR_ERR(skb));
- ret = -PTR_ERR(skb);
+ ret = PTR_ERR(skb);
goto out;
}
--
2.17.1
Re: [PATCH v3 06/26] s390/pci: Use PCI_STD_NUM_BARS
On Mon, Sep 16, 2019 at 11:41:38PM +0300, Denis Efremov wrote:
> Remove local definition PCI_BAR_COUNT for the number of PCI BARs and use
> global one PCI_STD_NUM_BARS instead.
>
> Acked-by: Sebastian Ott
> Cc: Gerald Schaefer
> Signed-off-by: Denis Efremov
> ---
> arch/s390/include/asm/pci.h | 5 +
> arch/s390/include/asm/pci_clp.h | 6 +++---
> arch/s390/pci/pci.c | 16
> arch/s390/pci/pci_clp.c | 6 +++---
> 4 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index a2399eff84ca..3a06c264ea53 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -2,9 +2,6 @@
> #ifndef __ASM_S390_PCI_H
> #define __ASM_S390_PCI_H
>
> -/* must be set before including pci_clp.h */
> -#define PCI_BAR_COUNT6
> -
> #include
> #include
> #include
> @@ -138,7 +135,7 @@ struct zpci_dev {
>
> char res_name[16];
> bool mio_capable;
> - struct zpci_bar_struct bars[PCI_BAR_COUNT];
> + struct zpci_bar_struct bars[PCI_STD_NUM_BARS];
>
> u64 start_dma; /* Start of available DMA addresses */
> u64 end_dma;/* End of available DMA addresses */
> diff --git a/arch/s390/include/asm/pci_clp.h b/arch/s390/include/asm/pci_clp.h
> index 50359172cc48..bd2cb4ea7d93 100644
> --- a/arch/s390/include/asm/pci_clp.h
> +++ b/arch/s390/include/asm/pci_clp.h
> @@ -77,7 +77,7 @@ struct mio_info {
> struct {
> u64 wb;
> u64 wt;
> - } addr[PCI_BAR_COUNT];
> + } addr[PCI_STD_NUM_BARS];
> u32 reserved[6];
> } __packed;
>
> @@ -98,9 +98,9 @@ struct clp_rsp_query_pci {
> u16 util_str_avail : 1; /* utility string available? */
> u16 pfgid : 8; /* pci function group id */
> u32 fid;/* pci function id */
> - u8 bar_size[PCI_BAR_COUNT];
> + u8 bar_size[PCI_STD_NUM_BARS];
> u16 pchid;
> - __le32 bar[PCI_BAR_COUNT];
> + __le32 bar[PCI_STD_NUM_BARS];
> u8 pfip[CLP_PFIP_NR_SEGMENTS]; /* pci function internal path */
> u32 : 16;
> u8 fmb_len;
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index b0e3b9a0e488..aca372c8e34f 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c
> @@ -43,7 +43,7 @@ static DECLARE_BITMAP(zpci_domain, ZPCI_NR_DEVICES);
> static DEFINE_SPINLOCK(zpci_domain_lock);
>
> #define ZPCI_IOMAP_ENTRIES \
> - min(((unsigned long) ZPCI_NR_DEVICES * PCI_BAR_COUNT / 2), \
> + min(((unsigned long) ZPCI_NR_DEVICES * PCI_STD_NUM_BARS / 2), \
> ZPCI_IOMAP_MAX_ENTRIES)
>
> static DEFINE_SPINLOCK(zpci_iomap_lock);
> @@ -294,7 +294,7 @@ static void __iomem *pci_iomap_range_mio(struct pci_dev
> *pdev, int bar,
> void __iomem *pci_iomap_range(struct pci_dev *pdev, int bar,
> unsigned long offset, unsigned long max)
> {
> - if (!pci_resource_len(pdev, bar) || bar >= PCI_BAR_COUNT)
> + if (bar >= PCI_STD_NUM_BARS || !pci_resource_len(pdev, bar))
> return NULL;
>
> if (static_branch_likely(&have_mio))
> @@ -324,7 +324,7 @@ static void __iomem *pci_iomap_wc_range_mio(struct
> pci_dev *pdev, int bar,
> void __iomem *pci_iomap_wc_range(struct pci_dev *pdev, int bar,
>unsigned long offset, unsigned long max)
> {
> - if (!pci_resource_len(pdev, bar) || bar >= PCI_BAR_COUNT)
> + if (bar >= PCI_STD_NUM_BARS || !pci_resource_len(pdev, bar))
> return NULL;
This looks like a latent bug fix here. If 'bar' is out of range we return
NULL instead accessing an invalid item of an array. Should this not be
a separate patch and tagged as stable?
Thanks,
Andrew Murray
>
> if (static_branch_likely(&have_mio))
> @@ -416,7 +416,7 @@ static void zpci_map_resources(struct pci_dev *pdev)
> resource_size_t len;
> int i;
>
> - for (i = 0; i < PCI_BAR_COUNT; i++) {
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> len = pci_resource_len(pdev, i);
> if (!len)
> continue;
> @@ -451,7 +451,7 @@ static void zpci_unmap_resources(struct pci_dev *pdev)
> if (zpci_use_mio(zdev))
> return;
>
> - for (i = 0; i < PCI_BAR_COUNT; i++) {
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> len = pci_resource_len(pdev, i);
> if (!len)
> continue;
> @@ -514,7 +514,7 @@ static int zpci_setup_bus_resources(struct zpci_dev *zdev,
> snprintf(zdev->res_name, sizeof(zdev->res_name),
>"PCI Bus %04x:%02x", zdev->domain, ZPCI_BUS_NR);
>
> - for (i = 0; i < PCI_BAR_COUNT; i++) {
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> if (!zdev->bars[i].size)
> continue;
>
Re: [PATCH] sched: fix an unused function "node_cpu" warning
On Tue, Sep 17, 2019 at 10:34:54AM -0400, Qian Cai wrote: > Clang reports a warning, > > kernel/locking/osq_lock.c:25:19: warning: unused function 'node_cpu' > [-Wunused-function] > > due to osq_lock() calls vcpu_is_preempted(node_cpu(node->prev))), but > vcpu_is_preempted() is compiled away. Fix it by converting the dummy > vcpu_is_preempted() from a macro to a proper static inline function. > > Signed-off-by: Qian Cai Acked-by: Mel Gorman -- Mel Gorman SUSE Labs
Re: [PATCH v2 2/3] i2c: qup: Remove dev_err() log after platform_get_irq*() failure
On 17/09/2019 19:21, Saiyam Doshi wrote:
> The debug message after platform_get_irq() failure is redundant
> because platform_get_irq() already prints an error. Thus remove it.
>
> Generated by: scripts/coccinelle/api/platform_get_irq.cocci
>
> Signed-off-by: Saiyam Doshi
> ---
> Changes in v2:
> Updated changelog and removed unnecessary braces after if condition.
>
> drivers/i2c/busses/i2c-qup.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 5519c19bfd9c..ed09a59066b2 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -1766,10 +1766,8 @@ static int qup_i2c_probe(struct platform_device *pdev)
> return PTR_ERR(qup->base);
>
> qup->irq = platform_get_irq(pdev, 0);
> - if (qup->irq < 0) {
> - dev_err(qup->dev, "No IRQ defined\n");
> + if (qup->irq < 0)
> return qup->irq;
> - }
As far as I understand, platform_get_irq() == 0 is also an error condition.
I think the typical way to handle this peculiarity is:
(Maybe the IRQ maintainers will correct me)
qup->irq = platform_get_irq(pdev, 0);
if (qup->irq <= 0)
return qup->irq ? : -ENXIO;
Regards.
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Wed, Sep 18, 2019 at 5:33 PM Greg KH wrote: > He did? I do not see a patch anywhere, what is the message-id of it? I'm just repeating myself at this point, but again, I'm more than willing to work on a patch. I just want to make it clear on how should I. > He took the "best known at the time" codebase, as we had nothing else to > work with. It wasn't the "best known at the time". sdFAT has been around now for years. Thanks.
Re: [PATCH stable 4.4 net] net: rds: Fix NULL ptr use in rds_tcp_kill_sock
On 2019/9/18 16:32, Greg KH wrote:
> On Wed, Sep 18, 2019 at 04:37:33PM +0800, Mao Wenan wrote:
>> After the commit c4e97b06cfdc ("net: rds: force to destroy
>> connection if t_sock is NULL in rds_tcp_kill_sock()."),
>> it introduced null-ptr-deref in rds_tcp_kill_sock as below:
>>
>> BUG: KASAN: null-ptr-deref on address 0020
>> Read of size 8 by task kworker/u16:10/910
>> CPU: 3 PID: 910 Comm: kworker/u16:10 Not tainted 4.4.178+ #3
>> Hardware name: linux,dummy-virt (DT)
>> Workqueue: netns cleanup_net
>> Call trace:
>> [] dump_backtrace+0x0/0x618
>> [] show_stack+0x38/0x60
>> [] dump_stack+0x1a8/0x230
>> [] kasan_report_error+0xc8c/0xfc0
>> [] kasan_report+0x94/0xd8
>> [] __asan_load8+0x88/0x150
>> [] rds_tcp_dev_event+0x734/0xb48
>> [] raw_notifier_call_chain+0x150/0x1e8
>> [] call_netdevice_notifiers_info+0x90/0x110
>> [] netdev_run_todo+0x2f4/0xb08
>> [] rtnl_unlock+0x2c/0x48
>> [] default_device_exit_batch+0x444/0x528
>> [] ops_exit_list+0x1c0/0x240
>> [] cleanup_net+0x738/0xbf8
>> [] process_one_work+0x96c/0x13e0
>> [] worker_thread+0x7e0/0x1910
>> [] kthread+0x304/0x390
>> [] ret_from_fork+0x10/0x50
>>
>> If the first loop add the tc->t_sock = NULL to the tmp_list,
>> 1). list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node)
>>
>> then the second loop is to find connections to destroy, tc->t_sock
>> might equal NULL, and tc->t_sock->sk happens null-ptr-deref.
>> 2). list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node)
>>
>> Fixes: c4e97b06cfdc ("net: rds: force to destroy connection if t_sock is
>> NULL in rds_tcp_kill_sock().")
>> Signed-off-by: Mao Wenan
>> ---
>> net/rds/tcp.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> Why is this not needed upstream as well?
Upstream does not use tc->t_sock in the second loop after below two patches.
afb4164d91c7 ("RDS: TCP: Refactor connection destruction to handle multiple
paths") and
2d746c93b6e5 ("rds: tcp: remove redundant function
rds_tcp_conn_paths_destroy()")
>
> 4.9.y? 4.14.y? anything else?
4.19.y and 4.14.y exist rds_tcp_conn_paths_destroy()
to guarantee that.
+static void rds_tcp_conn_paths_destroy(struct rds_connection *conn)
+{
+ struct rds_conn_path *cp;
+ struct rds_tcp_connection *tc;
+ int i;
+ struct sock *sk;
+
+ for (i = 0; i < RDS_MPATH_WORKERS; i++) {
+ cp = &conn->c_path[i];
+ tc = cp->cp_transport_data;
+ if (!tc->t_sock)
+ continue;
+ sk = tc->t_sock->sk;
+ sk->sk_prot->disconnect(sk, 0);
+ tcp_done(sk);
+ }
+}
+
>
> thanks,
>
> greg k-h
>
> .
>
RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Andre, > Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the > ARM SMC/HVC mailbox > > On Mon, 16 Sep 2019 09:44:37 + > Peng Fan wrote: > > Hi, > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 96 > ++ > > 1 file changed, 96 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..bf01bec035fc > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,96 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7Cff378bc3d622436c39ba08d73b94dfcc%7C686ea1d > 3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637043382928045369&sdata=rnx > KdDGjPPd > > +8VBI5WmgnZ3jxIjL2hcRYzbljfFxDkA0%3D&reserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7Cff378bc3d622436c39ba08d73b94dfcc%7C686ea1d3bc2b4c6 > fa92cd9 > > > +9c5c301635%7C0%7C1%7C637043382928045369&sdata=R02nWzpp9 > %2BrDYG9tA > > +ot4pdWb8tGGHet1MOjrD0dEjwA%3D&reserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > I think "or" instead of "and" is less confusing. ok > > > + call) instruction to trigger a mailbox-connected activity in > > + firmware, executing on the very same core as the caller. The value > > + of r0/w0/x0 the firmware returns after the smc call is delivered as > > + a received message to the mailbox framework, so synchronous > > + communication can be established. The exact meaning of the action > > + the mailbox triggers as well as the return value is defined by > > + their users and is not subject to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared > > One example use case of this mailbox ... > (to make it more obvious that it's not restricted to this) ok > > > + memory to transfer commands and parameters, and a mailbox to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, > > ... the described SMC function identifier, ok > > > + the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, > > identifier ok > > "passed from consumers": How? Where? > But I want to repeat: We should not allow this. This is a binding for a > mailbox > controller driver, not a generic firmware backdoor. As Jassi suggested the function identifier as an optional for mailbox driver. The driver should support function id passed from consumers. Currently there is no users for such case that passed from consumers, so I have no idea how. > We should be as strict as possible to avoid any security issues. > The firmware certainly knows the function ID it implements. The firmware > controls the DT. So it is straight-forward to put the ID into the DT. The > firmware could even do this at boot time, dynamically, before passing on the > DT to the non-secure world (bootloader or kernel). > > What would be the use case of this functionality? > > > or listed in the the arm,func-ids > >arm,func-id ok > > > + properties as described below. The firmware can return one value in > > property ok > > > + the first SMC result register, it is expected to be an error value, > > + which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: > > + compatible: > > +oneOf: >
Re: [PATCH] [v2] arm64: fix unreachable code issue with cmpxchg
On Tue, Sep 17, 2019 at 01:34:25PM -0700, Nathan Chancellor wrote:
> On Tue, Sep 10, 2019 at 01:56:22PM +0200, Arnd Bergmann wrote:
> > On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> > when CONFIG_OPTIMIZE_INLINING is set.
> > Clang then fails a compile-time assertion, because it cannot tell at
> > compile time what the size of the argument is:
> >
> > mm/memcontrol.o: In function `__cmpxchg_mb':
> > memcontrol.c:(.text+0x1a4c): undefined reference to
> > `__compiletime_assert_175'
> > memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26
> > against undefined symbol `__compiletime_assert_175'
> >
> > Mark all of the cmpxchg() style functions as __always_inline to
> > ensure that the compiler can see the result.
> >
> > Acked-by: Nick Desaulniers
> > Reported-by: Nathan Chancellor
> > Link: https://github.com/ClangBuiltLinux/linux/issues/648
> > Reviewed-by: Nathan Chancellor
> > Tested-by: Nathan Chancellor
> > Reviewed-by: Andrew Murray
> > Tested-by: Andrew Murray
> > Signed-off-by: Arnd Bergmann
> > ---
> > v2: skip unneeded changes, as suggested by Andrew Murray
> > ---
> > arch/arm64/include/asm/cmpxchg.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cmpxchg.h
> > b/arch/arm64/include/asm/cmpxchg.h
> > index a1398f2f9994..f9bef42c1411 100644
> > --- a/arch/arm64/include/asm/cmpxchg.h
> > +++ b/arch/arm64/include/asm/cmpxchg.h
> > @@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l,
> > "memory")
> > #undef __XCHG_CASE
> >
> > #define __XCHG_GEN(sfx)
> > \
> > -static inline unsigned long __xchg##sfx(unsigned long x, \
> > +static __always_inline unsigned long __xchg##sfx(unsigned long x, \
> > volatile void *ptr, \
> > int size) \
> > { \
> > @@ -148,7 +148,7 @@ __CMPXCHG_DBL(_mb)
> > #undef __CMPXCHG_DBL
> >
> > #define __CMPXCHG_GEN(sfx) \
> > -static inline unsigned long __cmpxchg##sfx(volatile void *ptr,
> > \
> > +static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr,
> > \
> >unsigned long old, \
> >unsigned long new, \
> >int size)\
> > @@ -255,7 +255,7 @@ __CMPWAIT_CASE( , , 64);
> > #undef __CMPWAIT_CASE
> >
> > #define __CMPWAIT_GEN(sfx) \
> > -static inline void __cmpwait##sfx(volatile void *ptr,
> > \
> > +static __always_inline void __cmpwait##sfx(volatile void *ptr,
> > \
> > unsigned long val,\
> > int size) \
> > { \
> > --
> > 2.20.0
> >
>
> Looks like the arm64 pull request happened without this patch so clang
> all{mod,yes}config builds are broken. Did the maintainers have any
> further comments on it or could this make it in with the next one?
Fear not! I plan to send this with some other fixes we've got for -rc1.
I just to get my CI scripts going again (new machine), but that shouldn't
take long.
Will
Re: printk meeting at LPC
On 2019-09-18, Sergey Senozhatsky wrote: >> Each console has its own iterator. This iterators will need to >> advance, regardless if the message was printed via write() or >> write_atomic(). > > Great. > > ->atomic_write() path will make sure that kthread is parked or will > those compete for uart port? A cpu-lock (probably per-console) will be used to synchronize the two. Unlike my RFCv1, we want to keep the cpu-lock out of the console drivers and we want it to be less aggressive (using trylock's instead of spinning). This should make the cpu-lock less "dangerous". I talked with PeterZ, Thomas, and PetrM about how this can be implemented, but there may still be some corner cases. I would like to put everything together now so that we can run and test if the decisions made in that meeting hold up for all the cases. I think it will be easier to identify/add the missing pieces, once we have it coded. John Ogness
Re: [PATCH v3 13/26] e1000: Use PCI_STD_NUM_BARS
On Mon, Sep 16, 2019 at 11:41:45PM +0300, Denis Efremov wrote:
> To iterate through all possible BARs, loop conditions refactored to the
> *number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
> valid BAR "i <= BAR_5". This is more idiomatic C style and allows to avoid
> the fencepost error.
>
> Cc: Jeff Kirsher
> Cc: "David S. Miller"
> Signed-off-by: Denis Efremov
> ---
> drivers/net/ethernet/intel/e1000/e1000.h | 1 -
> drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000.h
> b/drivers/net/ethernet/intel/e1000/e1000.h
> index c40729b2c184..7fad2f24dcad 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000.h
> +++ b/drivers/net/ethernet/intel/e1000/e1000.h
> @@ -45,7 +45,6 @@
>
> #define BAR_00
> #define BAR_11
> -#define BAR_55
No issue with this patch. However I noticed that at least 5 of the network
drivers have these same definitions, which are identical to the pci_barno enum
of include/linux/pci-epf.h. There are mostly used with pci_ioremap_bar and
pci_resource_** macros. I wonder if this is an indicator that these defintions
should live in the core.
Thanks,
Andrew Murray
>
> #define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
> PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index f703fa58458e..db4fd82036af 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -977,7 +977,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> goto err_ioremap;
>
> if (adapter->need_ioport) {
> - for (i = BAR_1; i <= BAR_5; i++) {
> + for (i = BAR_1; i < PCI_STD_NUM_BARS; i++) {
> if (pci_resource_len(pdev, i) == 0)
> continue;
> if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> --
> 2.21.0
>
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Fri, May 10, 2019 at 04:09:41PM -0400, J. Bruce Fields wrote:
> On Tue, May 07, 2019 at 10:24:58AM +1000, NeilBrown wrote:
> > Interesting perspective though doesn't NFSv4 explicitly allow
> > client-side ACL enforcement in the case of delegations?
>
> Not really. What you're probably thinking of is the single ACE that the
> server can return on granting a delegation, that tells the client it can
> skip the ACCESS check for users matching that ACE. It's unclear how
> useful that is. It's currently unused by the Linux client and server.
>
> > Not sure how relevant that is
> >
> > It seems to me we have two options:
> > 1/ declare the NFSv4 doesn't work as a lower layer for overlayfs and
> > recommend people use NFSv3, or
> > 2/ Modify overlayfs to work with NFSv4 by ignoring nfsv4 ACLs either
> > 2a/ always - and ignore all other acls and probably all system. xattrs,
> > or
> > 2b/ based on a mount option that might be
> > 2bi/ general "noacl" or might be
> > 2bii/ explicit "noxattr=system.nfs4acl"
> >
> > I think that continuing to discuss the miniature of the options isn't
> > going to help. No solution is perfect - we just need to clearly
> > document the implications of whatever we come up with.
> >
> > I lean towards 2a, but I be happy with with any '2' and '1' won't kill
> > me.
>
> I guess I'd also lean towards 2a.
>
> I don't think it applies to posix acls, as overlayfs is capable of
> copying those up and evaluating them on its own.
POSIX acls are evaluated and copied up.
I guess same goes for "security.*" attributes, that are evaluated on MAC checks.
I think it would be safe to ignore failure to copy up anything else. That seems
a bit saner than just blacklisting nfs4_acl...
Something like the following untested patch.
Thanks,
Miklos
---
fs/overlayfs/copy_up.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -36,6 +36,13 @@ static int ovl_ccup_get(char *buf, const
module_param_call(check_copy_up, ovl_ccup_set, ovl_ccup_get, NULL, 0644);
MODULE_PARM_DESC(check_copy_up, "Obsolete; does nothing");
+static bool ovl_must_copy_xattr(const char *name)
+{
+ return !strcmp(name, XATTR_POSIX_ACL_ACCESS) ||
+ !strcmp(name, XATTR_POSIX_ACL_DEFAULT) ||
+ !strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN);
+}
+
int ovl_copy_xattr(struct dentry *old, struct dentry *new)
{
ssize_t list_size, size, value_size = 0;
@@ -107,8 +114,13 @@ int ovl_copy_xattr(struct dentry *old, s
continue; /* Discard */
}
error = vfs_setxattr(new, name, value, size, 0);
- if (error)
- break;
+ if (error) {
+ if (ovl_must_copy_xattr(name))
+ break;
+
+ /* Ignore failure to copy unknown xattrs */
+ error = 0;
+ }
}
kfree(value);
out:
About getrandom(2) contract
Hi, Unlike other syscalls(like `read(2)`) `getrandom(2)`'s contract doesn't define what happens if you pass `buflen=0`, does the pointer still has to be valid? (what does valid even mean?) are there any side effects? i.e. is `getrandom(0x01, 0, 0)` undefined behavior?. Thanks, Elichai. -- PGP: 5607C93B5F86650C
RE: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, 16 Sep 2019 09:44:41 +
> Peng Fan wrote:
>
> Hi,
>
> looks quite good now, some smaller comments below.
> I think the only thing left is the "function ID passed by the client" topic.
>
> Have you tried using this interface using hvc, for instance in KVM or Xen? For
No. I do not have that implementation in hypervisor.
> instance to provide access to a clock for a passed-through platform device?
> Another use case that pops up from time to time is GPIO for guests. This
> sounds like a use case for using the register interface, also we could use the
> hvc return value.
>
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C58a1ed4078264d14958f08d73b95ed7e%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C1%7C637043387484474825&sdata=Cp1zlhlpQbg
> BsWu9ZDV
> > RKkXmd6kvUR%2BtPO7EPR7YLpA%3D&reserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 167
> > ++
> > 3 files changed, 176 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..c84aef39c8d9
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,167 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +#include
> > +
> > +struct arm_smc_chan_data {
> > + unsigned int function_id;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > + unsigned int function_id;
> > + union {
> > + unsigned int args_smccc32[6];
> > + unsigned long args_smccc64[6];
>
> Shouldn't this be u32 and u64 here, as the data type has this explicit length
> in
> the SMCCC?
ok
>
> > + };
> > +};
>
> If this is the data structure that this mailbox controller uses, I would
> expect
> this to be documented somewhere, or even exported.
Export this structure in include/linux/mailbox/smc-mailbox.h?
>
> And again, I don't like the idea of having the function ID in here.
You mean function_id in arm_smccc_mbox_cmd is not good?
>
> > +
> > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long);
> > +static smc_mbox_fn *invoke_smc_mbox_fn;
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + unsigned long ret;
> > + u32 function_id;
> > +
> > + function_id = chan_data->function_id;
> > + if (!functio
Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
On 17-09-19, 10:34, Sudeep Holla wrote: > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote: > > -device_initcall(qcom_cpufreq_hw_init); > > +postcore_initcall(qcom_cpufreq_hw_init); > > I am fine with core framework initcall pushed to earlier initcall levels > if required, but for individual/platform specific drivers I am not so > happy to see that. > > This goes against the grand plan of single common kernel strategy by > Android moving all drivers as modules. Its been long that I got the opportunity to work on drivers directly, but as far as I remember (which should be incorrect based on your reply) we can still build a driver as module even if it has some postcore_initcall() declarations. They will execute at module insertion. Is that incorrect ? If not, then how is it going to affect android effort ? -- viresh
Re: printk meeting at LPC
On (09/18/19 11:05), John Ogness wrote: > On 2019-09-18, Sergey Senozhatsky wrote: > >> Each console has its own iterator. This iterators will need to > >> advance, regardless if the message was printed via write() or > >> write_atomic(). > > > > Great. > > > > ->atomic_write() path will make sure that kthread is parked or will > > those compete for uart port? > > A cpu-lock (probably per-console) will be used to synchronize the > two. Unlike my RFCv1, we want to keep the cpu-lock out of the console > drivers and we want it to be less aggressive (using trylock's instead of > spinning). That's my expectation as well. cpu-lock and per-console kthread can live just fine in printk.c file. -ss
Re: [PATCH V7 2/3] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
On 09/15/2019 08:05 AM, Balbir Singh wrote:
>
>
> On 3/9/19 7:45 pm, Anshuman Khandual wrote:
>> The arm64 page table dump code can race with concurrent modification of the
>> kernel page tables. When a leaf entries are modified concurrently, the dump
>> code may log stale or inconsistent information for a VA range, but this is
>> otherwise not harmful.
>>
>> When intermediate levels of table are freed, the dump code will continue to
>> use memory which has been freed and potentially reallocated for another
>> purpose. In such cases, the dump code may dereference bogus addresses,
>> leading to a number of potential problems.
>>
>> Intermediate levels of table may by freed during memory hot-remove,
>> which will be enabled by a subsequent patch. To avoid racing with
>> this, take the memory hotplug lock when walking the kernel page table.
>>
>> Acked-by: David Hildenbrand
>> Acked-by: Mark Rutland
>> Signed-off-by: Anshuman Khandual
>> ---
>> arch/arm64/mm/ptdump_debugfs.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
>> index 064163f25592..b5eebc8c4924 100644
>> --- a/arch/arm64/mm/ptdump_debugfs.c
>> +++ b/arch/arm64/mm/ptdump_debugfs.c
>> @@ -1,5 +1,6 @@
>> // SPDX-License-Identifier: GPL-2.0
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -7,7 +8,10 @@
>> static int ptdump_show(struct seq_file *m, void *v)
>> {
>> struct ptdump_info *info = m->private;
>> +
>> +get_online_mems();
>> ptdump_walk_pgd(m, info);
>> +put_online_mems();
>
> Looks sane, BTW, checking other arches they might have the same race.
The problem can be present on other architectures which can dump kernel page
table during memory hot-remove operation where it actually frees up page table
pages. If there is no freeing involved the race condition here could cause
inconsistent or garbage information capture for a given VA range. Same is true
even for concurrent vmalloc() operations as well. But removal of page tables
pages can make it worse. Freeing page table pages during hot-remove is a
platform
decision, so would be adding these locks while walking kernel page table during
ptdump.
> Is there anything special about the arch?
AFAICS, no.
>
> Acked-by: Balbir Singh
>
>
Re: [PATCH 2/4] seccomp: add two missing ptrace ifdefines
On 2019-09-18 10:48:31, Christian Brauner wrote:
> Add tw missing ptrace ifdefines to avoid compilation errors on systems
> that do not provide PTRACE_EVENTMSG_SYSCALL_ENTRY or
> PTRACE_EVENTMSG_SYSCALL_EXIT or:
>
> gcc -Wl,-no-as-needed -Wall seccomp_bpf.c -lpthread -o seccomp_bpf
> In file included from seccomp_bpf.c:52:0:
> seccomp_bpf.c: In function ‘tracer_ptrace’:
> seccomp_bpf.c:1792:20: error: ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’ undeclared
> (first use in this function); did you mean ‘PTRACE_EVENT_CLONE’?
> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> ^
> ../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
> __typeof__(_expected) __exp = (_expected); \
> ^
> seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> ^
> seccomp_bpf.c:1792:20: note: each undeclared identifier is reported only once
> for each function it appears in
> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> ^
> ../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
> __typeof__(_expected) __exp = (_expected); \
> ^
> seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> ^
> seccomp_bpf.c:1793:6: error: ‘PTRACE_EVENTMSG_SYSCALL_EXIT’ undeclared (first
> use in this function); did you mean ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’?
> : PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
> ^
> ../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
> __typeof__(_expected) __exp = (_expected); \
> ^
> seccomp_bpf.c:1792:2: note: in expansion of macro ‘EXPECT_EQ’
> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> ^
>
> Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
I think this Fixes line is incorrect and should be changed to:
Fixes: 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
With that changed,
Reviewed-by: Tyler Hicks
Tyler
> Signed-off-by: Christian Brauner
> Cc: Kees Cook
> Cc: Andy Lutomirski
> Cc: Will Drewry
> Cc: Shuah Khan
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: Martin KaFai Lau
> Cc: Song Liu
> Cc: Yonghong Song
> Cc: Tycho Andersen
> CC: Tyler Hicks
> Cc: Jann Horn
> Cc: sta...@vger.kernel.org
> Cc: linux-kselft...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: b...@vger.kernel.org
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 6ef7f16c4cf5..ee52eab01800 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -155,6 +155,14 @@ struct seccomp_data {
> #ifndef PTRACE_SECCOMP_GET_METADATA
> #define PTRACE_SECCOMP_GET_METADATA 0x420d
>
> +#ifndef PTRACE_EVENTMSG_SYSCALL_ENTRY
> +#define PTRACE_EVENTMSG_SYSCALL_ENTRY 1
> +#endif
> +
> +#ifndef PTRACE_EVENTMSG_SYSCALL_EXIT
> +#define PTRACE_EVENTMSG_SYSCALL_EXIT 2
> +#endif
> +
> struct seccomp_metadata {
> __u64 filter_off; /* Input: which filter */
> __u64 flags; /* Output: filter's flags */
> --
> 2.23.0
>
Re: [PATCH 0/2] VMD fixes for v5.4
On Mon, Sep 16, 2019 at 07:54:33AM -0600, Jon Derrick wrote: > Hi Lorenzo, Bjorn, Keith, > > Please consider the following patches for 5.4 inclusion. > > These will apply to 5.2 stable. 4.19 has a few feature deps so I will instead > follow-up with a backport. > > Jon Derrick (2): > PCI: vmd: Fix config addressing when using bus offsets > PCI: vmd: Fix shadow offsets to reflect spec changes > > drivers/pci/controller/vmd.c | 25 +++-- > 1 file changed, 15 insertions(+), 10 deletions(-) I have pulled them into pci/vmd hopefully for v5.4. Thanks, Lorenzo
Re: [PATCH v3 17/26] vfio_pci: Loop using PCI_STD_NUM_BARS
On Mon, Sep 16, 2019 at 11:41:49PM +0300, Denis Efremov wrote:
> Refactor loops to use idiomatic C style and avoid the fencepost error
> of using "i < PCI_STD_RESOURCE_END" when "i <= PCI_STD_RESOURCE_END"
> is required, e.g., commit 2f686f1d9bee ("PCI: Correct PCI_STD_RESOURCE_END
> usage").
>
> To iterate through all possible BARs, loop conditions changed to the
> *number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
> valid BAR "i <= PCI_STD_RESOURCE_END".
>
> Cc: Cornelia Huck
> Cc: Alex Williamson
> Signed-off-by: Denis Efremov
> ---
> drivers/vfio/pci/vfio_pci.c | 11 ++
> drivers/vfio/pci/vfio_pci_config.c | 32 +++--
> drivers/vfio/pci/vfio_pci_private.h | 4 ++--
> 3 files changed, 26 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 703948c9fbe1..cb7d220d3246 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -110,13 +110,15 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
> static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev)
> {
> struct resource *res;
> - int bar;
> + int i;
> struct vfio_pci_dummy_resource *dummy_res;
>
> INIT_LIST_HEAD(&vdev->dummy_resources_list);
>
> - for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
> - res = vdev->pdev->resource + bar;
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> + int bar = i + PCI_STD_RESOURCES;
> +
> + res = &vdev->pdev->resource[bar];
Why can't we just drop PCI_STD_RESOURCES and replace it was 0. I understand
the abstraction here, but we don't do it elsewhere across the kernel. Is this
necessary?
Thanks,
Andrew Murray
>
> if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP))
> goto no_mmap;
> @@ -399,7 +401,8 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
>
> vfio_config_free(vdev);
>
> - for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> + bar = i + PCI_STD_RESOURCES;
> if (!vdev->barmap[bar])
> continue;
> pci_iounmap(pdev, vdev->barmap[bar]);
> diff --git a/drivers/vfio/pci/vfio_pci_config.c
> b/drivers/vfio/pci/vfio_pci_config.c
> index f0891bd8444c..90c0b80f8acf 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -450,30 +450,32 @@ static void vfio_bar_fixup(struct vfio_pci_device *vdev)
> {
> struct pci_dev *pdev = vdev->pdev;
> int i;
> - __le32 *bar;
> + __le32 *vbar;
> u64 mask;
>
> - bar = (__le32 *)&vdev->vconfig[PCI_BASE_ADDRESS_0];
> + vbar = (__le32 *)&vdev->vconfig[PCI_BASE_ADDRESS_0];
>
> - for (i = PCI_STD_RESOURCES; i <= PCI_STD_RESOURCE_END; i++, bar++) {
> - if (!pci_resource_start(pdev, i)) {
> - *bar = 0; /* Unmapped by host = unimplemented to user */
> + for (i = 0; i < PCI_STD_NUM_BARS; i++, vbar++) {
> + int bar = i + PCI_STD_RESOURCES;
> +
> + if (!pci_resource_start(pdev, bar)) {
> + *vbar = 0; /* Unmapped by host = unimplemented to user
> */
> continue;
> }
>
> - mask = ~(pci_resource_len(pdev, i) - 1);
> + mask = ~(pci_resource_len(pdev, bar) - 1);
>
> - *bar &= cpu_to_le32((u32)mask);
> - *bar |= vfio_generate_bar_flags(pdev, i);
> + *vbar &= cpu_to_le32((u32)mask);
> + *vbar |= vfio_generate_bar_flags(pdev, bar);
>
> - if (*bar & cpu_to_le32(PCI_BASE_ADDRESS_MEM_TYPE_64)) {
> - bar++;
> - *bar &= cpu_to_le32((u32)(mask >> 32));
> + if (*vbar & cpu_to_le32(PCI_BASE_ADDRESS_MEM_TYPE_64)) {
> + vbar++;
> + *vbar &= cpu_to_le32((u32)(mask >> 32));
> i++;
> }
> }
>
> - bar = (__le32 *)&vdev->vconfig[PCI_ROM_ADDRESS];
> + vbar = (__le32 *)&vdev->vconfig[PCI_ROM_ADDRESS];
>
> /*
>* NB. REGION_INFO will have reported zero size if we weren't able
> @@ -483,14 +485,14 @@ static void vfio_bar_fixup(struct vfio_pci_device *vdev)
> if (pci_resource_start(pdev, PCI_ROM_RESOURCE)) {
> mask = ~(pci_resource_len(pdev, PCI_ROM_RESOURCE) - 1);
> mask |= PCI_ROM_ADDRESS_ENABLE;
> - *bar &= cpu_to_le32((u32)mask);
> + *vbar &= cpu_to_le32((u32)mask);
> } else if (pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW) {
> mask = ~(0x2 - 1);
> mask |= PCI_ROM_ADDRESS_ENABLE;
> - *bar &= cpu_to_le32((u32)mask);
> + *vbar &= cpu_to_le32((u32)mask);
> } else
> -
