[PATCH v3] arm64: dts: ls1088a: add one more thermal zone node
Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core cluster
sensor is used to monitor the temperature of core and SoC platform is for
platform. The current dts only support the first sensor.
This patch adds the second sensor node to dts to enable it.
Signed-off-by: Yuantian Tang
---
v3:
- use more descriptive name for each zone
v2:
- Add more information about sensors to description
PS: In order to keep consistency to the first thermal-zone node, there will
be "WARNING: line over 80 characters" warnings.
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43 +--
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 661137f..54f973b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -129,19 +129,19 @@
};
thermal-zones {
- cpu_thermal: cpu-thermal {
+ core_cluster_thermal {
polling-delay-passive = <1000>;
polling-delay = <5000>;
thermal-sensors = < 0>;
trips {
- cpu_alert: cpu-alert {
+ core_cluster_alert: core_cluster-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- cpu_crit: cpu-crit {
+ core_cluster_crit: core_cluster-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -150,7 +150,42 @@
cooling-maps {
map0 {
- trip = <_alert>;
+ trip = <_cluster_alert>;
+ cooling-device =
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ platform-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = < 1>;
+
+ trips {
+ platform_alert: platform-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ platform_crit: platform-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <_alert>;
cooling-device =
< THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
< THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
--
1.7.1
Re: [PATCH] aio: prevent the final fput() in the middle of vfs_poll() (Re: KASAN: use-after-free Read in unix_dgram_poll)
On Sun, Mar 3, 2019 at 4:19 PM Al Viro wrote:
>
> On Sun, Mar 03, 2019 at 01:55:02PM +, Al Viro wrote:
>
> > Maybe unrelated to this bug, but... What's to prevent a wakeup
> > that happens just after we'd been added to a waitqueue by ->poll()
> > triggering aio_poll_wake(), which gets to aio_poll_complete()
> > with its fput() *before* we'd reached the end of ->poll() instance?
> >
> > I wonder if adding
> > get_file(req->file); // make sure that early completion is safe
> > right after
> > req->file = fget(iocb->aio_fildes);
> > if (unlikely(!req->file))
> > return -EBADF;
> > paired with
> > fput(req->file);
> > right after out: in aio_poll() is needed... Am I missing something
> > obvious here? Christoph?
>
> In more details - normally IOCB_CMD_POLL handling looks so:
>
> 1) io_submit(2) allocates aio_kiocb instance and passes it to aio_poll()
> 2) aio_poll() resolves the descriptor to struct file by
> req->file = fget(iocb->aio_fildes)
> 3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
> aio_kiocb to 2 (bumps by 1, that is).
> 4) aio_poll() calls vfs_poll(). After sanity checks (basically, "poll_wait()
> had been called and only once") it locks the queue. That's what the extra
> reference to iocb had been for - we know we can safely access it.
> 5) With queue locked, we check if ->woken has already been set to true
> (by aio_poll_wake()) and, if it had been, we unlock the queue, drop
> a reference to aio_kiocb and bugger off - at that point it's
> a responsibility to aio_poll_wake() and the stuff called/scheduled by
> it. That code will drop the reference to file in req->file, along
> with the other reference to our aio_kiocb.
> 6) otherwise, we see whether we need to wait. If we do, we unlock
> the queue, drop one reference to aio_kiocb and go away - eventual
> wakeup (or cancel) will deal with the reference to file and with the
> other reference to aio_kiocb
> 7) otherwise we remove ourselves from waitqueue (still under the queue
> lock), so that wakeup won't get us. No async activity will be happening,
> so we can safely drop req->file and iocb ourselves.
>
> If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
> won't get freed under us, so we can do all the checks and locking safely.
> And we don't touch ->file if we detect that case.
>
> However, vfs_poll() most certainly *does* touch the file it had been
> given. So wakeup coming while we are still in ->poll() might end up
> doing fput() on that file. That case is not too rare, and usually
> we are saved by the still present reference from descriptor table -
> that fput() is not the final one. But if another thread closes that
> descriptor right after our fget() and wakeup does happen before
> ->poll() returns, we are in trouble - final fput() done while we
> are in the middle of a method.
>
> What we need is to hold on to the file reference the same way we do with
> aio_kiocb. No need to store the reference to what we'd got in a separate
> variable - req->file is never reassigned and we'd already made sure that
> req won't be freed under us, so dropping the extra reference with
> fput(req->file) is fine in all cases.
>
> Fixes: bfe4037e722ec
> Cc: sta...@vger.kernel.org
> Signed-off-by: Al Viro
Please add the Reported-by tag from the report.
If you don't add it, then either:
1. somebody (you) will need to remember to later go and associate fix
the the report with "#syz fix" command
2. or the bug will stay open and syzbot will never report
use-after-frees in unix_dgram_poll again (it's still the same already
reported bug)
3. or worse somebody will spend time re-debugging this bug just to
find that you already fixed it but did not include the tag
Thanks
> ---
> diff --git a/fs/aio.c b/fs/aio.c
> index 3083180a54c8..7e88bfabdac2 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -1767,6 +1767,7 @@ static ssize_t aio_poll(struct aio_kiocb *aiocb, const
> struct iocb *iocb)
>
> /* one for removal from waitqueue, one for this function */
> refcount_set(>ki_refcnt, 2);
> + get_file(req->file);
>
> mask = vfs_poll(req->file, ) & req->events;
> if (unlikely(!req->head)) {
> @@ -1793,6 +1794,7 @@ static ssize_t aio_poll(struct aio_kiocb *aiocb, const
> struct iocb *iocb)
> spin_unlock_irq(>ctx_lock);
>
> out:
> + fput(req->file);
> if (unlikely(apt.error)) {
> fput(req->file);
> return apt.error;
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20190303151846.GQ2217%40ZenIV.linux.org.uk.
> For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm
Hi Su,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v5.0 next-20190301]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Su-Yanjun/net-xfrm-Add-_rcu-tag-for-rcu-protected-pointer-in-netns_xfrm/20190304-135248
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
All warnings (new ones prefixed by >>):
>> net/xfrm/xfrm_user.c:1198:39: sparse: warning: incorrect type in argument 1
>> (different address spaces)
net/xfrm/xfrm_user.c:1198:39: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1198:39: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1257:39: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1257:39: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1257:39: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1277:46: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1277:46: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1277:46: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1340:38: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1340:38: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1340:38: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1906:54: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1906:54: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1906:54: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:2065:38: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:2065:38: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:2065:38: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:2655:60: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:2655:60: sparse:expected struct sock *ssk
net/xfrm/xfrm_user.c:2655:60: sparse:got struct sock [noderef]
*nlsk
sparse warnings: (new ones prefixed by >>)
net/xfrm/xfrm_user.c:1198:39: sparse: warning: incorrect type in argument 1
(different address spaces)
>> net/xfrm/xfrm_user.c:1198:39: sparse:expected struct sock *sk
>> net/xfrm/xfrm_user.c:1198:39: sparse:got struct sock [noderef]
>> *nlsk
net/xfrm/xfrm_user.c:1257:39: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1257:39: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1257:39: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1277:46: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1277:46: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1277:46: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1340:38: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1340:38: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1340:38: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:1906:54: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:1906:54: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:1906:54: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:2065:38: sparse: warning: incorrect type in argument 1
(different address spaces)
net/xfrm/xfrm_user.c:2065:38: sparse:expected struct sock *sk
net/xfrm/xfrm_user.c:2065:38: sparse:got struct sock [noderef]
*nlsk
net/xfrm/xfrm_user.c:2655:60: sparse: warning: incorrect type in argument 1
(different address spaces)
>> net/xfrm/xfrm_user.c:2655:60: sparse:expected struct sock *ssk
net/xfrm/xfrm_user.c:2655:60: sparse:got struct sock [noderef]
*nlsk
vim +1198 net/xfrm/xfrm_user.c
880a6fab Christophe Gouault 2014-08-29 1180
ecfd6b18 Jamal Hadi Salim 2007-04-28 1181 static int
xfrm_get_spdinfo(struct sk_buff *skb, struct nlmsghdr *nlh,
5424f32e Thomas Graf 2007-08-22 1182 struct
nlattr **attrs)
ecfd6b18 Jamal Hadi Salim 2007-04-28 1183 {
a6483b79 Alexey Dobriyan 2008-11-25 1184 struct net *net
= sock_net(skb->sk);
ecfd6b18 Jamal Hadi Salim 2007-04-28 1185 struct sk_buff
*r_skb;
7b67c857 Thomas Graf 2007-08-22 1186 u32 *flags =
nlmsg_data(nlh);
15e47304 Eric W. Biederman2012-09-07 1187 u32 sportid =
NETLINK_CB(skb).portid;
ecfd6b18 Jamal Hadi Salim 2007-04-28
Re: BUG: unable to handle kernel paging request in bpf_prog_kallsyms_add
On Mon, Sep 10, 2018 at 10:31 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:f6f3bac08ff9 tools/bpf: bpftool: add net support > git tree: bpf-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1794005640 > kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6 > dashboard link: https://syzkaller.appspot.com/bug?extid=c827a78260579449ad39 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1611c7e140 This is still very actively happening. See the dashboard link for info about more crashes. > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+c827a78260579449a...@syzkaller.appspotmail.com > > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** > ** > BUG: unable to handle kernel paging request at c90001930002 > PGD 1da948067 P4D 1da948067 PUD 1da949067 PMD 1d49da067 PTE 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 12601 Comm: syz-executor3 Not tainted 4.19.0-rc2+ #93 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:bpf_prog_kallsyms_candidate kernel/bpf/core.c:472 [inline] > RIP: 0010:bpf_prog_kallsyms_add+0xbe/0x9b0 kernel/bpf/core.c:483 > Code: d0 31 c0 e8 14 68 f3 ff 49 8d 7c 24 02 48 89 f8 48 89 fa 48 c1 e8 03 > 83 e2 07 0f b6 04 18 38 d0 7f 08 84 c0 0f 85 39 07 00 00 <41> 0f b6 5c 24 > 02 31 ff 83 e3 01 89 de e8 b0 68 f3 ff 84 db 0f 84 > RSP: 0018:8801bc2af9c0 EFLAGS: 00010246 > RAX: RBX: dc00 RCX: 818c8b39 > RDX: 0002 RSI: 818b671c RDI: c90001930002 > RBP: 8801bc2afb30 R08: 8801bf750100 R09: ed003b584732 > R10: ed003b584732 R11: 8801dac23993 R12: c9000193 > R13: 8801bc2afd18 R14: R15: 110037855f3d > FS: 7fb5d21c9700() GS:8801dac0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: c90001930002 CR3: 0001bcd1c000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > bpf_prog_load+0x13d1/0x1cb0 kernel/bpf/syscall.c:1442 > __do_sys_bpf kernel/bpf/syscall.c:2371 [inline] > __se_sys_bpf kernel/bpf/syscall.c:2333 [inline] > __x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2333 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457099 > Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fb5d21c8c78 EFLAGS: 0246 ORIG_RAX: 0141 > RAX: ffda RBX: 7fb5d21c96d4 RCX: 00457099 > RDX: 0048 RSI: 2000 RDI: 0005 > RBP: 009300a0 R08: R09: > R10: R11: 0246 R12: > R13: 004cb9c8 R14: 004c335d R15: > Modules linked in: > Dumping ftrace buffer: > (ftrace buffer empty) > CR2: c90001930002 > ---[ end trace fcb4474011e9b55c ]--- > RIP: 0010:bpf_prog_kallsyms_candidate kernel/bpf/core.c:472 [inline] > RIP: 0010:bpf_prog_kallsyms_add+0xbe/0x9b0 kernel/bpf/core.c:483 > Code: d0 31 c0 e8 14 68 f3 ff 49 8d 7c 24 02 48 89 f8 48 89 fa 48 c1 e8 03 > 83 e2 07 0f b6 04 18 38 d0 7f 08 84 c0 0f 85 39 07 00 00 <41> 0f b6 5c 24 > 02 31 ff 83 e3 01 89 de e8 b0 68 f3 ff 84 db 0f 84 > RSP: 0018:8801bc2af9c0 EFLAGS: 00010246 > RAX: RBX: dc00 RCX: 818c8b39 > RDX: 0002 RSI: 818b671c RDI: c90001930002 > RBP: 8801bc2afb30 R08: 8801bf750100 R09: ed003b584732 > R10: ed003b584732 R11: 8801dac23993 R12: c9000193 > R13: 8801bc2afd18 R14: R15: 110037855f3d > FS: 7fb5d21c9700() GS:8801dac0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: c90001930002 CR3: 0001bcd1c000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > > -- > You received this message because you are subscribed to the Google
Re: [PATCH] percpu/module resevation: change resevation size iff X86_VSMP is set
Greetings Barret,
On 3/1/19 8:30 PM, Barret Rhoden wrote:
> Hi -
>
> On 01/21/2019 06:47 AM, Eial Czerwacki wrote:
>>
>
> Your main issue was that you only sent this patch to LKML, but not the
> maintainers of the file. If you don't, your patch might get lost. To
> get the appropriate people and lists, run:
>
> scripts/get_maintainer.pl YOUR_PATCH.patch.
>
> For this patch, you'll get this:
>
> Dennis Zhou (maintainer:PER-CPU MEMORY ALLOCATOR)
> Tejun Heo (maintainer:PER-CPU MEMORY ALLOCATOR)
> Christoph Lameter (maintainer:PER-CPU MEMORY ALLOCATOR)
> linux-kernel@vger.kernel.org (open list)
>
> I added the three maintainers to this email.
>
> I have a few minor comments below.
>
thanks, I did not knew that, I'll use it next time.
>> [PATCH] percpu/module resevation: change resevation size iff X86_VSMP
> is set
>
> You misspelled 'reservation'. Also, I'd just say: "percpu: increase
> module reservation size if X86_VSMP is set". ('change' -> 'increase'),
> only says 'reservation' once.)
>
>> as reported in bug #201339
>> (https://bugzilla.kernel.org/show_bug.cgi?id=201339)
>
> I think you can add a tag for this right above your Signed-off-by tags.
> e.g.:
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201339
>
>> by enabling X86_VSMP, INTERNODE_CACHE_BYTES's definition differs from
>> the default one
>> causing the struct size to exceed the size ok 8KB.
> ^of
>
will fix, thanks.
> Which struct are you talking about? I have one in mind, but others
> might not know from reading the commit message.
>
> I ran into this on https://bugzilla.kernel.org/show_bug.cgi?id=202511.
> In that case, it was because modules (drm and amdkfd) were using
> DEFINE_SRCU, which does a DEFINE_PER_CPU on struct srcu_data, and that
> used cacheline_internodealigned_in_smp.
you are correct, the structure in question is struct srcu_data.
>
>>
>> in order to avoid such issue, increse PERCPU_MODULE_RESERVE to 64KB if
>> CONFIG_X86_VSMP is set.
> ^increase
>
>>
>> the value was caculated on linux 4.20.3, make allmodconfig all and the
>> following oneliner:
> ^calculated
>
will fix, thanks.
>> for f in `find -name *.ko`; do echo $f; readelf -S $f |grep perc;
>> done |grep data..percpu -B 1 |grep ko |while read r; do echo -n "$r:
>> "; objdump --syms --section=.data..percpu $r|grep data |sort -n |awk
>> '{c++; d=strtonum("0x" $1) + strtonum("0x" $5); if (m < d) m = d;} END
>> {printf("%d vars-> last addr 0x%x ( %d )\n", c, m, m)}' ; done |column
>> -t |sort -k 8 -n | awk '{print $8}'| paste -sd+ | bc
>
> Not sure how useful the one-liner is, versus a description of what
> you're doing. i.e. "the size of all module percpu data sections, or
> something."
I thought an easy reproducing will suffice, I'll take that into account.
>
> Also, how close was that calculated value to 64K? If more modules start
> using DEFINE_SRCU, each of which uses 8K, then that 64K might run out.
the biggest module was 12472 bytes in size, as multiple modules uses the
same percpu, more is needed, the only way I was able to make it fit was 64K.
of course there is a possibility that at a specific scenario 64K will
not be enough but we have yet to encounter such scenario.
>
> Thanks,
> Barret
>
>> Signed-off-by: Eial Czerwacki
>> Signed-off-by: Shai Fultheim
>> Signed-off-by: Oren Twaig
>> ---
>> include/linux/percpu.h | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
>> index 70b7123..6b79693 100644
>> --- a/include/linux/percpu.h
>> +++ b/include/linux/percpu.h
>> @@ -14,7 +14,11 @@
>> /* enough to cover all DEFINE_PER_CPUs in modules */
>> #ifdef CONFIG_MODULES
>> +#ifdef X86_VSMP
>> +#define PERCPU_MODULE_RESERVE (1 << 16)
>> +#else
>> #define PERCPU_MODULE_RESERVE (8 << 10)
>> +#endif
>> #else
>> #define PERCPU_MODULE_RESERVE 0
>> #endif
>>
>
>
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote: > > Hi, guys > > I also hit the following issue. but it fails to reproduce the issue by the > log. > > it seems to the case that we access the mm->owner and deference it will > result in the UAF. > But it should not be possible that we specify the incomplete process to be > the mm->owner. > > Any thoughts? FWIW syzbot was able to reproduce this with this reproducer. This looks like a very subtle race (threaded reproducer that runs repeatedly in multiple processes), so most likely we are looking for something like few instructions inconsistency window. > Thanks, > zhong jiang > > On 2018/12/4 23:43, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:0072a0c14d5b Merge tag 'media/v4.20-4' of git://git.kernel.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=11c885a340 > > kernel config: https://syzkaller.appspot.com/x/.config?x=b9cc5a440391cbfd > > dashboard link: https://syzkaller.appspot.com/bug?extid=cbb52e396df3e565ab02 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12835e2540 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172fa5a340 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+cbb52e396df3e565a...@syzkaller.appspotmail.com > > > > cgroup: fork rejected by pids controller in /syz2 > > == > > BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:182 > > [inline] > > BUG: KASAN: use-after-free in task_css include/linux/cgroup.h:477 [inline] > > BUG: KASAN: use-after-free in mem_cgroup_from_task mm/memcontrol.c:815 > > [inline] > > BUG: KASAN: use-after-free in get_mem_cgroup_from_mm.part.62+0x6d7/0x880 > > mm/memcontrol.c:844 > > Read of size 8 at addr 8881b72af310 by task syz-executor198/9332 > > > > CPU: 0 PID: 9332 Comm: syz-executor198 Not tainted 4.20.0-rc5+ #142 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0x244/0x39d lib/dump_stack.c:113 > > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > > kasan_report_error mm/kasan/report.c:354 [inline] > > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > > __read_once_size include/linux/compiler.h:182 [inline] > > task_css include/linux/cgroup.h:477 [inline] > > mem_cgroup_from_task mm/memcontrol.c:815 [inline] > > get_mem_cgroup_from_mm.part.62+0x6d7/0x880 mm/memcontrol.c:844 > > get_mem_cgroup_from_mm mm/memcontrol.c:834 [inline] > > mem_cgroup_try_charge+0x608/0xe20 mm/memcontrol.c:5888 > > mcopy_atomic_pte mm/userfaultfd.c:71 [inline] > > mfill_atomic_pte mm/userfaultfd.c:418 [inline] > > __mcopy_atomic mm/userfaultfd.c:559 [inline] > > mcopy_atomic+0xb08/0x2c70 mm/userfaultfd.c:609 > > userfaultfd_copy fs/userfaultfd.c:1705 [inline] > > userfaultfd_ioctl+0x29fb/0x5610 fs/userfaultfd.c:1851 > > vfs_ioctl fs/ioctl.c:46 [inline] > > file_ioctl fs/ioctl.c:509 [inline] > > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > > __do_sys_ioctl fs/ioctl.c:720 [inline] > > __se_sys_ioctl fs/ioctl.c:718 [inline] > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > RIP: 0033:0x44c7e9 > > Code: 5d c5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 0f 83 2b c5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7f906b69fdb8 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: 006e4a08 RCX: 0044c7e9 > > RDX: 2100 RSI: c028aa03 RDI: 0004 > > RBP: 006e4a00 R08: R09: > > R10: R11: 0246 R12: 006e4a0c > > R13: 7ffdfd47813f R14: 7f906b6a09c0 R15: 002d > > > > Allocated by task 9325: > > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > > set_track mm/kasan/kasan.c:460 [inline] > > kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 > > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 > > kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644 > > alloc_task_struct_node kernel/fork.c:158 [inline] > > dup_task_struct kernel/fork.c:843 [inline] > > copy_process+0x2026/0x87a0 kernel/fork.c:1751 > > _do_fork+0x1cb/0x11d0 kernel/fork.c:2216 > > __do_sys_clone kernel/fork.c:2323 [inline] > > __se_sys_clone kernel/fork.c:2317 [inline] > > __x64_sys_clone+0xbf/0x150 kernel/fork.c:2317 > > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > >
Re: [RFC PATCH 2/2] ceph: quota: fix quota subdir mounts
On Sat, Mar 2, 2019 at 3:13 AM Luis Henriques wrote:
>
> The CephFS kernel client doesn't enforce quotas that are set in a
> directory that isn't visible in the mount point. For example, given the
> path '/dir1/dir2', if quotas are set in 'dir1' and the mount is done in with
>
> mount -t ceph ::/dir1/ /mnt
>
> then the client can't access the 'dir1' inode from the quota realm dir2
> belongs to.
>
> This patch fixes this by simply doing an MDS LOOKUPINO Op and grabbing a
> reference to it (so that it doesn't disappear again). This also requires an
> extra field in ceph_snap_realm so that we know we have to release that
> reference when destroying the realm.
>
This may cause circle reference if somehow an inode owned by snaprealm
get moved into mount subdir (other clients do rename). how about
holding these inodes in mds_client?
> Links: https://tracker.ceph.com/issues/3848
> Reported-by: Hendrik Peyerl
> Signed-off-by: Luis Henriques
> ---
> fs/ceph/caps.c | 2 +-
> fs/ceph/quota.c | 30 +++---
> fs/ceph/snap.c | 3 +++
> fs/ceph/super.h | 2 ++
> 4 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index bba28a5034ba..e79994ff53d6 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -1035,7 +1035,7 @@ static void drop_inode_snap_realm(struct
> ceph_inode_info *ci)
> list_del_init(>i_snap_realm_item);
> ci->i_snap_realm_counter++;
> ci->i_snap_realm = NULL;
> - if (realm->ino == ci->i_vino.ino)
> + if ((realm->ino == ci->i_vino.ino) && !realm->own_inode)
> realm->inode = NULL;
> spin_unlock(>inodes_with_caps_lock);
> ceph_put_snap_realm(ceph_sb_to_client(ci->vfs_inode.i_sb)->mdsc,
> diff --git a/fs/ceph/quota.c b/fs/ceph/quota.c
> index 9455d3aef0c3..f6b972d222e4 100644
> --- a/fs/ceph/quota.c
> +++ b/fs/ceph/quota.c
> @@ -22,7 +22,16 @@ void ceph_adjust_quota_realms_count(struct inode *inode,
> bool inc)
> static inline bool ceph_has_realms_with_quotas(struct inode *inode)
> {
> struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> - return atomic64_read(>quotarealms_count) > 0;
> + struct super_block *sb = mdsc->fsc->sb;
> +
> + if (atomic64_read(>quotarealms_count) > 0)
> + return true;
> + /* if root is the real CephFS root, we don't have quota realms */
> + if (sb->s_root->d_inode &&
> + (sb->s_root->d_inode->i_ino == CEPH_INO_ROOT))
> + return false;
> + /* otherwise, we can't know for sure */
> + return true;
> }
>
> void ceph_handle_quota(struct ceph_mds_client *mdsc,
> @@ -166,6 +175,7 @@ static bool check_quota_exceeded(struct inode *inode,
> enum quota_check_op op,
> return false;
>
> down_read(>snap_rwsem);
> +restart:
> realm = ceph_inode(inode)->i_snap_realm;
> if (realm)
> ceph_get_snap_realm(mdsc, realm);
> @@ -176,8 +186,22 @@ static bool check_quota_exceeded(struct inode *inode,
> enum quota_check_op op,
> spin_lock(>inodes_with_caps_lock);
> in = realm->inode ? igrab(realm->inode) : NULL;
> spin_unlock(>inodes_with_caps_lock);
> - if (!in)
> - break;
> + if (!in) {
> + up_read(>snap_rwsem);
> + in = ceph_lookup_inode(inode->i_sb, realm->ino);
> + down_read(>snap_rwsem);
> + if (IS_ERR(in)) {
> + pr_warn("Can't lookup inode %llx (err:
> %ld)\n",
> + realm->ino, PTR_ERR(in));
> + break;
> + }
> + spin_lock(>inodes_with_caps_lock);
> + realm->inode = in;
> + realm->own_inode = true;
> + spin_unlock(>inodes_with_caps_lock);
> + ceph_put_snap_realm(mdsc, realm);
> + goto restart;
> + }
>
> ci = ceph_inode(in);
> spin_lock(>i_ceph_lock);
> diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c
> index f74193da0e09..c84ed8e8526a 100644
> --- a/fs/ceph/snap.c
> +++ b/fs/ceph/snap.c
> @@ -117,6 +117,7 @@ static struct ceph_snap_realm *ceph_create_snap_realm(
>
> atomic_set(>nref, 1);/* for caller */
> realm->ino = ino;
> + realm->own_inode = false;
> INIT_LIST_HEAD(>children);
> INIT_LIST_HEAD(>child_item);
> INIT_LIST_HEAD(>empty_item);
> @@ -184,6 +185,8 @@ static void __destroy_snap_realm(struct ceph_mds_client
> *mdsc,
> kfree(realm->prior_parent_snaps);
> kfree(realm->snaps);
> ceph_put_snap_context(realm->cached_context);
> + if (realm->own_inode && realm->inode)
> + iput(realm->inode);
> kfree(realm);
Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread
On (02/12/19 15:29), John Ogness wrote:
[..]
> + /* the printk kthread never exits */
> + for (;;) {
> + ret = prb_iter_wait_next(, buf,
> + PRINTK_RECORD_MAX, _seq);
> + if (ret == -ERESTARTSYS) {
> + continue;
> + } else if (ret < 0) {
> + /* iterator invalid, start over */
> + prb_iter_init(, _rb, NULL);
> + continue;
> + }
> +
> + msg = (struct printk_log *)buf;
> + format_text(msg, master_seq, ext_text, _len, text,
> + , printk_time);
> +
> + console_lock();
> + if (len > 0 || ext_len > 0) {
> + call_console_drivers(ext_text, ext_len, text, len);
> + boot_delay_msec(msg->level);
> + printk_delay();
> + }
> + console_unlock();
> + }
This, theoretically, creates a whole new world of possibilities for
console drivers. Now they can do GFP_KERNEL allocations and stall
printk_kthread during OOM; or they can explicitly reschedule from
->write() callback (via console_conditional_schedule()) because
console_lock() sets console_may_schedule.
It's one thing to do cond_resched() (or to let preemption to take over)
after call_console_drivers() (when we are done printing a message to all
console drivers) and another thing to let preemption to take over while
we are printing a messages to the consoles. It probably would make sense
to disable preemption around call_console_drivers().
-ss
Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
On Sun, Mar 03, 2019 at 04:11:28PM -0500, Kimberly Brown wrote:
> On Sun, Mar 03, 2019 at 09:05:43AM +0100, Greg KH wrote:
> > On Fri, Mar 01, 2019 at 02:18:24PM -0500, Kimberly Brown wrote:
> > > +/*
> > > + * Channel-level attribute_group callback function. Returns the
> > > permission for
> > > + * each attribute, and returns 0 if an attribute is not visible.
> > > + */
> > > +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> > > + struct attribute *attr, int idx)
> > > +{
> > > + const struct vmbus_channel *channel =
> > > + container_of(kobj, struct vmbus_channel, kobj);
> > > +
> > > + /* Hide the monitor attributes if the monitor mechanism is not used. */
> > > + if (!channel->offermsg.monitor_allocated &&
> > > + (attr == _attr_pending.attr ||
> > > + attr == _attr_latency.attr ||
> > > + attr == _attr_monitor_id.attr))
> > > + return 0;
> > > +
> > > + return attr->mode;
> > > +}
> > > +
> > > +static struct attribute_group vmbus_chan_group = {
> > > + .attrs = vmbus_chan_attrs,
> > > + .is_visible = vmbus_chan_attr_is_visible
> > > +};
> > > +
> > > static struct kobj_type vmbus_chan_ktype = {
> > > .sysfs_ops = _chan_sysfs_ops,
> > > .release = vmbus_chan_release,
> > > - .default_attrs = vmbus_chan_attrs,
> >
> > Why did you remove this line?
>
> I removed the default attributes because vmbus_chan_attrs contains
> non-default attributes. You suggested that I use one attribute_group and
> an is_visible() callback for the device-level attributes (see
> https://lore.kernel.org/lkml/20190226081848.ga15...@kroah.com/). I
> assumed (possibly incorrectly) that I should do the same for these
> channel-level attributes.
That is fine to have a callback, but why did you have to remove the
default attribute pointer? The two should have nothing to do with each
other.
> > > };
> > >
> > > /*
> > > @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev,
> > > struct vmbus_channel *channel)
> > > if (ret)
> > > return ret;
> > >
> > > + ret = sysfs_create_group(kobj, _chan_group);
> >
> > Why are you adding these "by hand"? What was wrong with using the
> > default attribute group pointer? You also are not removing the
> > attributes :(
>
> Are you referring to default_attrs in kobj_type? It's not an
> attribute_group pointer, it's a pointer to an attribute pointer array.
> The problem with using default_attrs is that all of the attributes are
> visible.
It shouldn't, the is_visable() callback will be called on each attribute
when the group is created by the core. Did that not work properly when
you tested this?
> I'm fairly certain that the monitor attributes are being removed.
> sysfs_create_group() uses the attribute_group's is_visible() callback to
> control the attribute visibility. And, when I look at the sysfs files, I
> can see that the monitor sysyfs files are removed.
I mean you are not removing the group when the device goes away, not
that the individual files are not present. If you leave the pointer to
default_attributes there, the core will properly remove the sysfs
attributes when the device is removed from the system. Otherwise you
just "get lucky" if the attributes are removed or not.
> In v3, I proposed moving the monitor attributes to a special
> attribute_group and adding that group manually when needed. Do you
> prefer that approach for the channel-level monitor attributes?
No need for a special group here, just use the is_visable() callback
like you currently are, all should be fine. I think you are adding more
code than you need to in order to get this to all work properly :)
thanks,
greg k-h
Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask
On Sun, 2019-03-03 at 14:53 +, Jonathan Cameron wrote: > [External] > > > On Sun, 3 Mar 2019 11:01:09 -0300 > Renato Lui Geh wrote: > > > On 03/01, Ardelean, Alexandru wrote: > > > On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote: > > > > > > > > > > > > The ad7780 supports both the ad778x and ad717x families. Each chip > > > > has > > > > a corresponding ID. This patch provides a mask for extracting ID > > > > values > > > > from the status bits and also macros for the correct values for the > > > > ad7170, ad7171, ad7780 and ad7781. > > > > > > > > Signed-off-by: Renato Lui Geh > > > > --- > > > > drivers/staging/iio/adc/ad7780.c | 8 ++-- > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/staging/iio/adc/ad7780.c > > > > b/drivers/staging/iio/adc/ad7780.c > > > > index 56c49e28f432..ad7617a3a141 100644 > > > > --- a/drivers/staging/iio/adc/ad7780.c > > > > +++ b/drivers/staging/iio/adc/ad7780.c > > > > @@ -26,10 +26,14 @@ > > > > #define AD7780_RDY BIT(7) > > > > #define AD7780_FILTER BIT(6) > > > > #define AD7780_ERR BIT(5) > > > > -#define AD7780_ID1 BIT(4) > > > > -#define AD7780_ID0 BIT(3) > > > > #define AD7780_GAINBIT(2) > > > > > > > > +#define AD7170_ID 0 > > > > +#define AD7171_ID 1 > > > > +#define AD7780_ID 1 > > > > +#define AD7781_ID 0 > > > > + > > > > +#define AD7780_ID_MASK (BIT(3) | BIT(4)) > > > > > > This also doesn't have any functionality change. > > > The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused > > > (maybe > > > in a later patch they are ?). > > > > They aren't. I added them following a previous review suggestion. > > Should > > I remove them? > > Can we check them? It's always useful to confirm that the device is > the one you think it is. Then we can either use what is there > with a suitable warning, or if that is tricky just fault out as the > dt is giving us the wrong part number. > > J I guess `dev_warn_ratelimited()` could be used to make sure syslog isn't spammed-to-death when doing multiple conversions, and the ID isn't correct. Since these IDs are read after you get a sample, I'm a bit fearful of log- spam. I wouldn't throw an error in the ad7780_postprocess_sample() for this, but warning [with rate-limit] sounds reasonable. > > > > > > > I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place, > > > since > > > they're easier matched with the datasheet. > > > > > > > > > > > #define AD7780_PATTERN_GOOD1 > > > > #define AD7780_PATTERN_MASKGENMASK(1, 0) > > > > -- > > > > 2.21.0 > > > > > >
Re: [PATCH v3 10/12] hikey960: Support usb functionality of Hikey960
Hi, On 2019/3/4 14:55, Andy Shevchenko wrote: > On Mon, Mar 4, 2019 at 4:35 AM Chen Yu wrote: >> On 2019/3/3 0:01, Andy Shevchenko wrote: >>> On Sat, Mar 2, 2019 at 11:05 AM Yu Chen wrote: > +config HISI_HIKEY_USB + tristate "USB functionality of HiSilicon Hikey Platform" + depends on OF && GPIOLIB + help + If you say yes here you get support for usb functionality of HiSilicon Hikey Platform. >>> +#include >>> >>> It's hard to see why this have >>> depends on OF followed by above header inclusion. >>> >> This driver depends on devicetree, so I add "depends on OF". >> But is seems that "#include " can be removed after "of_" API >> have been removed. Thanks for your reminder! > > So, it means that technically there is no such dependency, rather > administratively. > OK. I will remove the dependent next version. + hisi_hikey_usb->typec_vbus = devm_gpiod_get(dev, "typec-vbus", + GPIOD_OUT_LOW); >>> + if (!hisi_hikey_usb->typec_vbus) + return -ENOENT; >>> >>> Hmm... Is it possible to get NULL pointer from gpiod_get() at all? >>> + if (!hisi_hikey_usb->otg_switch) + return -ENOENT; >>> >>> Ditto. >>> >> I check the comments of devm_gpio_get API, it will not return NULL pointer. >> But is it more safe to keep the NULL checking? What is your advice? > > Why do we need dead code? > OK.I will remove it. Thanks Yu Chen
[PATCH v2] io: accel: kxcjk1013: restore the range after resume.
From: "he, bo"
On some laptops, kxcjk1013 is powered off when system enters S3. We need
restore the range regiter during resume. Otherwise, the sensor doesn't
work properly after S3.
Signed-off-by: he, bo
Signed-off-by: Chen, Hu
---
Changes in v2:
- Handle return value independently in resume callback.
drivers/iio/accel/kxcjk-1013.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
index 7096e577b23f..17837e26bcf2 100644
--- a/drivers/iio/accel/kxcjk-1013.c
+++ b/drivers/iio/accel/kxcjk-1013.c
@@ -1437,6 +1437,11 @@ static int kxcjk1013_resume(struct device *dev)
mutex_lock(>mutex);
ret = kxcjk1013_set_mode(data, OPERATION);
+ if (ret < 0) {
+ mutex_unlock(>mutex);
+ return ret;
+ }
+ ret = kxcjk1013_set_range(data, data->range);
mutex_unlock(>mutex);
return ret;
--
2.20.1
Re: [PATCH v4 5/9] staging: iio: ad7780: move regulator to after GPIO init
On Sat, 2019-03-02 at 19:11 +, Jonathan Cameron wrote:
> [External]
>
>
> On Fri, 1 Mar 2019 07:38:45 +
> "Ardelean, Alexandru" wrote:
>
> > On Thu, 2019-02-28 at 11:25 -0300, Renato Lui Geh wrote:
> > >
> > >
> > > To maintain consistency between ad7780_probe and ad7780_remove
> > > orders,
> > > regulator initialization has been moved to after GPIO
> > > initializations.
> > >
> > > Signed-off-by: Renato Lui Geh
> > > ---
> > > drivers/staging/iio/adc/ad7780.c | 26 +-
> > > 1 file changed, 13 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/adc/ad7780.c
> > > b/drivers/staging/iio/adc/ad7780.c
> > > index ad7617a3a141..12aef0f101bc 100644
> > > --- a/drivers/staging/iio/adc/ad7780.c
> > > +++ b/drivers/staging/iio/adc/ad7780.c
> > > @@ -255,16 +255,6 @@ static int ad7780_probe(struct spi_device *spi)
> > >
> > > ad_sd_init(>sd, indio_dev, spi,
> > > _sigma_delta_info);
> > >
> > > - st->reg = devm_regulator_get(>dev, "avdd");
> > > - if (IS_ERR(st->reg))
> > > - return PTR_ERR(st->reg);
> > > -
> > > - ret = regulator_enable(st->reg);
> > > - if (ret) {
> > > - dev_err(>dev, "Failed to enable specified AVdd
> > > supply\n");
> > > - return ret;
> > > - }
> > > -
> > > st->chip_info =
> > > _chip_info_tbl[spi_get_device_id(spi)-
> > > > driver_data];
> > >
> > > @@ -284,7 +274,7 @@ static int ad7780_probe(struct spi_device *spi)
> > > ret = PTR_ERR(st->powerdown_gpio);
> > > dev_err(>dev, "Failed to request powerdown GPIO:
> > > %d\n",
> > > ret);
> > > - goto error_disable_reg;
> > > + return ret;
> > > }
> > >
> > > if (st->chip_info->is_ad778x) {
> > > @@ -295,7 +285,7 @@ static int ad7780_probe(struct spi_device *spi)
> > > ret = PTR_ERR(st->gain_gpio);
> > > dev_err(>dev, "Failed to request gain
> > > GPIO:
> > > %d\n",
> > > ret);
> > > - goto error_disable_reg;
> > > + return ret;
> > > }
> > >
> > > st->filter_gpio = devm_gpiod_get_optional(>dev,
> > > @@ -306,10 +296,20 @@ static int ad7780_probe(struct spi_device *spi)
> > > dev_err(>dev,
> > > "Failed to request filter GPIO:
> > > %d\n",
> > > ret);
> > > - goto error_disable_reg;
> > > + return ret;
> > > }
> > > }
> > >
> > > + st->reg = devm_regulator_get(>dev, "avdd");
> > > + if (IS_ERR(st->reg))
> > > + return PTR_ERR(st->reg);
> > > +
> > > + ret = regulator_enable(st->reg);
> > > + if (ret) {
> > > + dev_err(>dev, "Failed to enable specified AVdd
> > > supply\n");
> > > + return ret;
> > > + }
> > > +
> >
> > I'm probably missing something, but other than the fact that this moves
> > the
> > regulator init after the GPIOs init, it doesn't change much.
> > The order of the probe & remove is more-or-less the same.
> > The GPIOs will be free'd via devm_ API/stuff.
>
> This is another one from me. I'm a fanatic at times when it comes
> to probe and remove orders being precise reverses. It just makes
> review easier. Nice to not actually have to think.
>
> So I agree there is no 'actual' effect but it is in my view
> still worth doing.
Ack.
Let's leave it
>
> Jonathan
>
> >
> >
> > > ret = ad_sd_setup_buffer_and_trigger(indio_dev);
> > > if (ret)
> > > goto error_disable_reg;
> > > --
> > > 2.21.0
> > >
>
>
Re: MT76x2U crashes XHCI driver on AMD Ryzen system
On Sun, Mar 3, 2019 at 11:10 PM Stanislaw Gruszka wrote:
>
> On Thu, Feb 28, 2019 at 02:40:29PM +0100, Joerg Roedel wrote:
> > On Thu, Feb 28, 2019 at 01:19:48PM +0100, Stanislaw Gruszka wrote:
> > > Nevermind, the patch is wrong, s->dma_address is initalized in
> > > sg_num_pages().
> >
> > Yes, it is. In sg_num_pages() the offset into the IOMMU mapping is
> > stored in s->dma_address, taking also the segment boundary mask into
> > account. map_sg() later only adds the base-address to that.
>
> I have some more info about the issues in
> https://bugzilla.kernel.org/show_bug.cgi?id=202673
>
> We have some bugs in mt76. Apparently we should not use
> page_frag_alloc() with size bigger than PAGE_SIZE as page_frag_alloc()
> can fallback to single page allocation. And also we should not make
> sizes unaligned as pointed in commit:
> 3bed3cc4156e ("net: Do not allocate page fragments that are not skb aligned"
As a small and totally unrelated note, page_frag_alloc is only used in
mt76 and the nvme driver ;)
>
> However after fixing that mt76usb still did not work. To make things
> work we had to change rx frag size from 2048 to PAGE_SIZE and change
> virt_to_head_page() to virt_to_page() when setting SG's.
>
> I think I understand why first change was needed. If we do 2 separate
> dma maps of 2 different buffers in single page i.e (PAGE + off=0
> and PAGE + off=2048) it causes problem. So either map_sg() return
> error which mt76usb does not handle correctly or there is issue
> in AMD IOMMU because two dma maps use the same page.
>
> But I don't understand why the second change was needed. Without
> it we have issue with incorrect page->_refcount . It is somehow
> related with AMD IOMMU, because on different platforms we do not
> have such problems.
>
> Joerg, could you look at this ? Thanks.
>
> Stanislaw
RE: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Dear Greg-san: I confirmed our company email related counter person that below footer is added automatically after we send email to who doesn't work in our company. I am very sorry that I didn't notice this issue and make you confuse. Now I am confirming with our counter person whether there is solution to not add below footer. After that, I will re-send patch mail to you. Best Regards Jacky -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Monday, March 04, 2019 2:23 PM To: Cao, Jacky Cc: oneu...@suse.com; st...@rowland.harvard.edu; linux-...@vger.kernel.org; linux-s...@vger.kernel.org; usb-stor...@lists.one-eyed-alien.net; linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port On Mon, Mar 04, 2019 at 02:08:54AM +, jacky@sony.com wrote: > > > This email is confidential and intended only for the use of the individual or > entity named above and may contain information that is privileged. If you are > not the intended recipient, you are notified that any dissemination, > distribution or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by return email or > telephone and destroy the original message. - This mail is sent via Sony Asia > Pacific Mail Gateway.. This footer requires me to delete this email as it is not compatible with doing Linux kernel development. greg k-h This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. - This mail is sent via Sony Asia Pacific Mail Gateway..
Re: [PATCH v4 3/9] staging: iio: ad7780: set pattern values and masks directly
On Sat, 2019-03-02 at 19:08 +, Jonathan Cameron wrote:
> [External]
>
>
> On Sat, 2 Mar 2019 19:07:16 +
> Jonathan Cameron wrote:
>
> > On Fri, 1 Mar 2019 07:17:04 +
> > "Ardelean, Alexandru" wrote:
> >
> > > On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote:
> > > >
> > > >
> > > > The AD7780 driver contains status pattern bits designed for
> > > > checking
> > > > whether serial transfers have been correctly performed. Pattern
> > > > macros
> > > > were previously generated through bit fields. This patch sets good
> > > > pattern values directly and masks through GENMASK.
> > > >
> > > > Signed-off-by: Renato Lui Geh
> > > > ---
> > > > drivers/staging/iio/adc/ad7780.c | 20 +---
> > > > 1 file changed, 9 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/iio/adc/ad7780.c
> > > > b/drivers/staging/iio/adc/ad7780.c
> > > > index 7a68e90ddf14..56c49e28f432 100644
> > > > --- a/drivers/staging/iio/adc/ad7780.c
> > > > +++ b/drivers/staging/iio/adc/ad7780.c
> > > > @@ -17,6 +17,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include
> > > > #include
> > > > @@ -28,16 +29,13 @@
> > > > #define AD7780_ID1 BIT(4)
> > > > #define AD7780_ID0 BIT(3)
> > > > #define AD7780_GAINBIT(2)
> > > > -#define AD7780_PAT1BIT(1)
> > > > -#define AD7780_PAT0BIT(0)
> > >
> > > I don't see a problem to leave the bitfields; they can be read &
> > > matched
> > > easier with the datasheet.
> > >
> > > >
> > > > -#define AD7780_PATTERN (AD7780_PAT0)
> > > > -#define AD7780_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1)
> > > >
> > > > -#define AD7170_PAT2BIT(2)
> > > > +#define AD7780_PATTERN_GOOD1
> > >
> > > It was also nice before that the PAT0..PAT2 bitfields were used to
> > > define a
> > > good pattern, since it's easier to match with the datasheet.
> >
> > This one was much suggestion. Not particularly important one.
>
> Not enough sleep this week clearly :)
> This one was _my_ suggestion.
Ok.
I assumed a bit I missed a discussion somewhere.
Let's have this as-is here.
I don't mind it much either.
My [personal] feeling is that [in the context of a move-out-of-staging-of-
this-driver] this patch is a bit of noise.
If the series were more tidy-up, then I probably would not have replied.
>
> >
> > Personally if a datasheet is pointlessly confusing I tend to ignore it.
> > This is a two bit field as the bits don't have independent meaning!
> >
> > I'm not strongly tied to it though and as it's an Analog driver and
> > you all do a good job maintaining the set I'll go with your preference!
> > I do prefer the naming of PATTERN_GOOD though if nothing else!
> > >
> > >
> > > > +#define AD7780_PATTERN_MASKGENMASK(1, 0)
> > >
> > > I like the general usage of GENMASK, but I'm not sure in this case
> > > it's
> > > worth doing. Maybe I missed a discussion somewhere, about doing this
> > > change, but it is mostly a cosmetic without any functional change.
> > >
> > >
> > > >
> > > > -#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> > > > -#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 |
> > > > AD7170_PAT2)
> > > > +#define AD7170_PATTERN_GOOD5
> > > > +#define AD7170_PATTERN_MASKGENMASK(2, 0)
> > > >
> > > > #define AD7780_GAIN_MIDPOINT 64
> > > > #define AD7780_FILTER_MIDPOINT 13350
> > > > @@ -209,25 +207,25 @@ static const struct ad_sigma_delta_info
> > > > ad7780_sigma_delta_info = {
> > > > static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
> > > > [ID_AD7170] = {
> > > > .channel = AD7170_CHANNEL(12, 24),
> > > > - .pattern = AD7170_PATTERN,
> > > > + .pattern = AD7170_PATTERN_GOOD,
> > > > .pattern_mask = AD7170_PATTERN_MASK,
> > > > .is_ad778x = false,
> > > > },
> > > > [ID_AD7171] = {
> > > > .channel = AD7170_CHANNEL(16, 24),
> > > > - .pattern = AD7170_PATTERN,
> > > > + .pattern = AD7170_PATTERN_GOOD,
> > > > .pattern_mask = AD7170_PATTERN_MASK,
> > > > .is_ad778x = false,
> > > > },
> > > > [ID_AD7780] = {
> > > > .channel = AD7780_CHANNEL(24, 32),
> > > > - .pattern = AD7780_PATTERN,
> > > > + .pattern = AD7780_PATTERN_GOOD,
> > > > .pattern_mask = AD7780_PATTERN_MASK,
> > > > .is_ad778x = true,
> > > > },
> > > > [ID_AD7781] = {
> > > > .channel = AD7780_CHANNEL(20, 32),
> > > > - .pattern = AD7780_PATTERN,
> > > > + .pattern = AD7780_PATTERN_GOOD,
> > > > .pattern_mask = AD7780_PATTERN_MASK,
> > > > .is_ad778x = true,
> > > > },
> > > > --
> > > > 2.21.0
> > > >
>
>
Re: [PATCH v2] drm/bridge: sil_sii8620: make remote control optional.
On 04.03.2019 03:13, Life is hard, and then you die wrote: > On Thu, Jan 24, 2019 at 05:33:55PM -0800, Ronald Tschalär wrote: >> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency >> of RC_CORE) changed the driver to select both RC_CORE and INPUT. >> However, this causes problems with other drivers, in particular an input >> driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate >> commit): >> >> drivers/clk/Kconfig:9:error: recursive dependency detected! >> drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by >> MFD_INTEL_LPSS >> drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by >> MFD_INTEL_LPSS_PCI >> drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by >> KEYBOARD_APPLESPI >> drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on >> INPUT >> drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 >> drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on >> DRM_BRIDGE >> drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by >> DRM_PL111 >> drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on >> COMMON_CLK >> >> According to the docs and general consensus, select should only be used >> for non user-visible symbols, but both RC_CORE and INPUT are >> user-visible. Furthermore almost all other references to INPUT >> throughout the kernel config are depends, not selects. For this reason >> the first part of this change reverts commit d6abe6df706c. >> >> In order to address the original reason for commit d6abe6df706c, namely >> that not all boards use the remote controller functionality and hence >> should not need have to deal with RC_CORE, the second part of this >> change now makes the remote control support in the driver optional and >> contingent on RC_CORE being defined. And with this the hard dependency >> on INPUT also goes away as that is only needed if RC_CORE is defined >> (which in turn already depends on INPUT). >> >> CC: Inki Dae >> CC: Andrzej Hajda >> CC: Laurent Pinchart >> CC: Dmitry Torokhov >> Signed-off-by: Ronald Tschalär >> --- >> Resending this, as I somehow managed to forget to cc dri-devel. >> Apologies for the duplication. >> >> Changes in v2: >> - completely remove dependencies on both RC_CORE and INPUT in Kconfig, >> - make remote control functionality in driver contingent on RC_CORE >>being defined >> >> drivers/gpu/drm/bridge/Kconfig | 2 -- >> drivers/gpu/drm/bridge/sil-sii8620.c | 17 + >> 2 files changed, 17 insertions(+), 2 deletions(-) > [snip] > > Is there anything I can do to help get this reviewed and moved forward? Addressing my comments [1] ? :) Ah I see, for some reasons (my mistake apparently) my response was not sent to you, sorry. [1]: https://lkml.org/lkml/2019/1/28/258 Regards Andrzej > > > Cheers, > > Ronald > > >
linux-next: Tree for Mar 4
Hi all, Please do not add any code destined for v5.2 to your linux-next included branches until after v5.1-rc1 has been released. News: I will not be doing linux-next releases from next Thursday (Mar 7) to the following Friday (Mar 15). Sorry this happened to fall across most of the merge window. Changes since 20190301: The kvm tree gained a conflict against Linus' tree. The drivers-x86 tree gained a conflict against the watchdog tree. Non-merge commits (relative to Linus' tree): 10954 10914 files changed, 489355 insertions(+), 252184 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 297 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (c027c7cf1577 Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc) Merging fixes/master (ed3ce4cfc919 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (6f6c95f09001 ASN.1: mark expected switch fall-through) Merging kbuild-current/fixes (207a369e3c08 sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE) Merging arc-current/for-curr (85d6adcbbe6d ARC: boot log: cut down on verbosity) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (74698f6971f2 arm64: Relax GIC version check during early boot) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (8f5b27347e88 powerpc/powernv/sriov: Register IOMMU groups for VFs) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (46b1c18f9deb net: sched: put back q.qlen into a single location) Merging bpf/master (07f12b26e21a net: sit: fix memory leak in sit_init_net()) Merging ipsec/master (d235c48b40d3 net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X) Merging netfilter/master (ecef67cb10db tun: remove unnecessary memory barrier) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d5fa9c55e5f3 Merge tag 'mlx5-updates-2019-03-01' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging mac80211/master (d235c48b40d3 net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X) Merging rdma-fixes/for-rc (f09ef134a7ca iw_cxgb4: cq/qp mask depends on bar2 pages in a host page) Merging sound-current/for-linus (a634090a0f24 ALSA: usb-audio: Add quirk for MOTU MicroBook II) Merging sound-asoc-fixes/for-linus (b5e806ae4ad8 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (8cd0aeaa0868 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (22e78ec655e8 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6) Merging tty.current/tty-linus (d13937116f1e Linux 5.0-rc6) Merging usb.current/usb-linus (d13937116f1e Linux 5.0-rc6) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy:
Re: MT76x2U crashes XHCI driver on AMD Ryzen system
On Thu, Feb 28, 2019 at 02:40:29PM +0100, Joerg Roedel wrote:
> On Thu, Feb 28, 2019 at 01:19:48PM +0100, Stanislaw Gruszka wrote:
> > Nevermind, the patch is wrong, s->dma_address is initalized in
> > sg_num_pages().
>
> Yes, it is. In sg_num_pages() the offset into the IOMMU mapping is
> stored in s->dma_address, taking also the segment boundary mask into
> account. map_sg() later only adds the base-address to that.
I have some more info about the issues in
https://bugzilla.kernel.org/show_bug.cgi?id=202673
We have some bugs in mt76. Apparently we should not use
page_frag_alloc() with size bigger than PAGE_SIZE as page_frag_alloc()
can fallback to single page allocation. And also we should not make
sizes unaligned as pointed in commit:
3bed3cc4156e ("net: Do not allocate page fragments that are not skb aligned"
However after fixing that mt76usb still did not work. To make things
work we had to change rx frag size from 2048 to PAGE_SIZE and change
virt_to_head_page() to virt_to_page() when setting SG's.
I think I understand why first change was needed. If we do 2 separate
dma maps of 2 different buffers in single page i.e (PAGE + off=0
and PAGE + off=2048) it causes problem. So either map_sg() return
error which mt76usb does not handle correctly or there is issue
in AMD IOMMU because two dma maps use the same page.
But I don't understand why the second change was needed. Without
it we have issue with incorrect page->_refcount . It is somehow
related with AMD IOMMU, because on different platforms we do not
have such problems.
Joerg, could you look at this ? Thanks.
Stanislaw
[PATCH] sky2: Disable MSI on Dell Inspiron 1545 and Gateway P-79
Some sky2 chips fire IRQ after S3, before the driver is fully resumed:
[ 686.804877] do_IRQ: 1.37 No irq handler for vector
This is likely a platform bug that device isn't fully quiesced during
S3. Use MSI-X, maskable MSI or INTx can prevent this issue from
happening.
Since MSI-X and maskable MSI are not supported by this device, fallback
to use INTx on affected platforms.
BugLink: https://bugs.launchpad.net/bugs/1807259
BugLink: https://bugs.launchpad.net/bugs/1809843
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/marvell/sky2.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index 57727fe1501e..8b3495ee2b6e 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
@@ -93,7 +94,7 @@ static int copybreak __read_mostly = 128;
module_param(copybreak, int, 0);
MODULE_PARM_DESC(copybreak, "Receive copy threshold");
-static int disable_msi = 0;
+static int disable_msi = -1;
module_param(disable_msi, int, 0);
MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
@@ -4917,6 +4918,24 @@ static const char *sky2_name(u8 chipid, char *buf, int
sz)
return buf;
}
+static const struct dmi_system_id msi_blacklist[] = {
+ {
+ .ident = "Dell Inspiron 1545",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1545"),
+ },
+ },
+ {
+ .ident = "Gateway P-79",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Gateway"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P-79"),
+ },
+ },
+ {}
+};
+
static int sky2_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct net_device *dev, *dev1;
@@ -5028,6 +5047,9 @@ static int sky2_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto err_out_free_pci;
}
+ if (disable_msi == -1)
+ disable_msi = !!dmi_check_system(msi_blacklist);
+
if (!disable_msi && pci_enable_msi(pdev) == 0) {
err = sky2_test_msi(hw);
if (err) {
--
2.17.1
Re: [PATCH v3 10/12] hikey960: Support usb functionality of Hikey960
hi, On Mon, 2019-03-04 at 08:50 +0200, Andy Shevchenko wrote: > On Mon, Mar 4, 2019 at 3:47 AM Chunfeng Yun wrote: > > On Sat, 2019-03-02 at 17:05 +0800, Yu Chen wrote: > > > > + hisi_hikey_usb->role_sw = usb_role_switch_get(dev); > > > + if (!hisi_hikey_usb->role_sw) > > > + return -EPROBE_DEFER; > > Here return EPROBE_DEFFER means the related device_connection is > > registered after this probe is called, right? > > if not, use IS_ERR_OR_NULL then return PTR_ERR is enough > > How enough? If return value is NULL it would be transformered to 0, > which is success return code from the ->probe() which means we will > have ->probed() and not functional device. > You are right:) > Am I missing something? >
Re: [PATCH v6 1/3] PCI: altera: Add Stratix 10 PCIe support
On Fri, 2019-03-01 at 14:15 +, Lorenzo Pieralisi wrote:
> On Fri, Mar 01, 2019 at 08:50:48AM +0800, Ley Foon Tan wrote:
> >
> > On Thu, 2019-02-28 at 10:56 +, Lorenzo Pieralisi wrote:
> > >
> > > On Thu, Feb 28, 2019 at 06:52:50PM +0800, Ley Foon Tan wrote:
> > >
> > > [...]
> > >
> > > >
> > > >
> > > > +static int s10_tlp_read_packet(struct altera_pcie *pcie, u32
> > > > *value)
> > > > +{
> > > > + int i;
> > > > + u32 ctrl;
> > > > + u32 comp_status;
> > > > + u32 dw[4];
> > > > + u32 count;
> > > > +
> > > > + for (i = 0; i < TLP_LOOP; i++) {
> > > > + ctrl = cra_readl(pcie, S10_RP_RXCPL_STATUS);
> > > > + if (!(ctrl & RP_RXCPL_SOP)) {
> > > > + udelay(5);
> > > > + continue;
> > > > + }
> > > > +
> > > > + /* Read first DW */
> > > > + dw[0] = cra_readl(pcie, S10_RP_RXCPL_REG);
> > > > + count = 1;
> > > > +
> > > > + /* Poll for EOP */
> > > > + for (i = 0; i < TLP_LOOP && count <
> > > > ARRAY_SIZE(dw); i++) {
> > > > + ctrl = cra_readl(pcie,
> > > > S10_RP_RXCPL_STATUS);
> > > > + dw[count++] = cra_reeadl(pcie,
> > > > S10_RP_RXCPL_REG);
> > > > + if (ctrl & RP_RXCPL_EOP) {
> > > > + comp_status =
> > > > TLP_COMP_STATUS(dw[1]);
> > > > + if (comp_status)
> > > > + return
> > > > PCIBIOS_DEVICE_NOT_FOUND;
> > > > +
> > > > + if (value &&
> > > > + TLP_BYTE_COUNT(dw[1])
> > > > ==
> > > > sizeof(u32) &&
> > > > + count == 4)
> > > > + *value = dw[3];
> > > > +
> > > > + return PCIBIOS_SUCCESSFUL;
> > > > + }
> > > Two more things.
> > >
> > > - Why don't you need a udelay() in the inner loop ?
> > It has received start of packet (SOP) when in the inner loop, next
> > DW
> > will come on next. So, I don't add udelay here.
> > >
> > > - I think that count >= ARRAY_SIZE(dw) in the inner loop is an
> > > error
> > > ?? condition and it should be flagged up with a warning before
> > > exiting.
> > Yes, please add this.
> > >
> > >
> > > I can make these changes if you let me know your thoughts on
> > > this.
> > Please go ahead and change this.
> I rewrote the loop.
>
> Please have a look at my branch not-to-merge/pci-altera, if that's
> OK and it passes the kbot tests I will try to get it upstream.
>
> Lorenzo
We need return error if (i >= TLP_LOOP). Other than that is okay.
+ if (i >= TLP_LOOP)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
I also attached a patch in attachment to fix the Sparse warnings.
You can squash it to this patch.
Thanks.
Regards
Ley Foon
>
> >
> > Thanks.
> >
> > Regards
> > Ley Foon
> > >
> > >
> > > Lorenzo
> > >
> > > >
> > > >
> > > > + }
> > > > + }
> > > > +
> > > > + return PCIBIOS_DEVICE_NOT_FOUND;
> > > > +}
> > > > +
> > > > ??static void tlp_write_packet(struct altera_pcie *pcie, u32
> > > > *headers,
> > > > ?? ??u32 data, bool align)
> > > > ??{
> > > > @@ -210,6 +306,15 @@ static void tlp_write_packet(struct
> > > > altera_pcie *pcie, u32 *headers,
> > > > ?? tlp_write_tx(pcie, _rp_regdata);
> > > > ??}
> > > > ??
> > > > +static void s10_tlp_write_packet(struct altera_pcie *pcie, u32
> > > > *headers,
> > > > + ??u32 data, bool dummy)
> > > > +{
> > > > + s10_tlp_write_tx(pcie, headers[0], RP_TX_SOP);
> > > > + s10_tlp_write_tx(pcie, headers[1], 0);
> > > > + s10_tlp_write_tx(pcie, headers[2], 0);
> > > > + s10_tlp_write_tx(pcie, data, RP_TX_EOP);
> > > > +}
> > > > +
> > > > ??static int tlp_cfg_dword_read(struct altera_pcie *pcie, u8
> > > > bus,
> > > > u32 devfn,
> > > > ?? int where, u8 byte_en,
> > > > u32 *value)
> > > > ??{
> > > > @@ -219,9 +324,9 @@ static int tlp_cfg_dword_read(struct
> > > > altera_pcie *pcie, u8 bus, u32 devfn,
> > > > ?? headers[1] = TLP_CFG_DW1(pcie, TLP_READ_TAG,
> > > > byte_en);
> > > > ?? headers[2] = TLP_CFG_DW2(bus, devfn, where);
> > > > ??
> > > > - tlp_write_packet(pcie, headers, 0, false);
> > > > + pcie->pcie_data->ops->tlp_write_pkt(pcie, headers, 0,
> > > > false);
> > > > ??
> > > > - return tlp_read_packet(pcie, value);
> > > > + return pcie->pcie_data->ops->tlp_read_pkt(pcie,
> > > > value);
> > > > ??}
> > > > ??
> > > > ??static int tlp_cfg_dword_write(struct altera_pcie *pcie, u8
> > > > bus,
> > > > u32 devfn,
> > > > @@ -236,11 +341,13 @@ static int tlp_cfg_dword_write(struct
> > > > altera_pcie *pcie, u8 bus, u32 devfn,
> > > > ??
> > > > ??
Re: [PATCH v3 10/12] hikey960: Support usb functionality of Hikey960
On Mon, Mar 4, 2019 at 4:35 AM Chen Yu wrote: > On 2019/3/3 0:01, Andy Shevchenko wrote: > > On Sat, Mar 2, 2019 at 11:05 AM Yu Chen wrote: > >> +config HISI_HIKEY_USB > >> + tristate "USB functionality of HiSilicon Hikey Platform" > >> + depends on OF && GPIOLIB > >> + help > >> + If you say yes here you get support for usb functionality of > >> HiSilicon Hikey Platform. > > > >> +#include > > > > It's hard to see why this have > > depends on OF followed by above header inclusion. > > > This driver depends on devicetree, so I add "depends on OF". > But is seems that "#include " can be removed after "of_" API > have been removed. Thanks for your reminder! So, it means that technically there is no such dependency, rather administratively. > >> + hisi_hikey_usb->typec_vbus = devm_gpiod_get(dev, "typec-vbus", > >> + GPIOD_OUT_LOW); > > > >> + if (!hisi_hikey_usb->typec_vbus) > >> + return -ENOENT; > > > > Hmm... Is it possible to get NULL pointer from gpiod_get() at all? > > > >> + if (!hisi_hikey_usb->otg_switch) > >> + return -ENOENT; > > > > Ditto. > > > I check the comments of devm_gpio_get API, it will not return NULL pointer. > But is it more safe to keep the NULL checking? What is your advice? Why do we need dead code? -- With Best Regards, Andy Shevchenko
Re: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
On Mon, Mar 04, 2019 at 06:46:32AM +, Andy Tang wrote:
>
>
> > -Original Message-
> > From: Shawn Guo
> > Sent: 2019年3月4日 14:21
> > To: Andy Tang
> > Cc: Leo Li ; robh...@kernel.org; mark.rutl...@arm.com;
> > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; linux...@vger.kernel.org;
> > daniel.lezc...@linaro.org; rui.zh...@intel.com; edubez...@gmail.com
> > Subject: Re: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
> >
> > On Mon, Mar 04, 2019 at 11:21:11AM +0800, Yuantian Tang wrote:
> > > Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core
> > > cluster sensor is used to monitor the temperature of core and SoC
> > > platform is for platform. The current dts only support the first sensor.
> > > This patch adds the second sensor node to dts to enable it.
> > >
> > > Signed-off-by: Yuantian Tang
> > > ---
> > > v2:
> > > - Add more information about sensors to description
> > > PS: In order to keep consistency to the first thermal-zone node, there
> > > will be "WARNING: line over 80 characters" warnings.
> > >
> > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43
> > +--
> > > 1 files changed, 39 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > index 661137f..9f52bc9 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > @@ -129,19 +129,19 @@
> > > };
> > >
> > > thermal-zones {
> > > - cpu_thermal: cpu-thermal {
> > > + ccu {
> >
> > Is this change really necessary? What does 'ccu' stand for?
> I think so. ccu stands for core cluster unit. cpu is too general.
> On some platforms, there are more than one core clusters.
> At least we should change it to "core cluster" if short form is not
> appropriate.
Yes, please give it a more descriptive name.
Shawn
Re: [PATCH v3 10/12] hikey960: Support usb functionality of Hikey960
On Mon, Mar 4, 2019 at 3:47 AM Chunfeng Yun wrote: > On Sat, 2019-03-02 at 17:05 +0800, Yu Chen wrote: > > + hisi_hikey_usb->role_sw = usb_role_switch_get(dev); > > + if (!hisi_hikey_usb->role_sw) > > + return -EPROBE_DEFER; > Here return EPROBE_DEFFER means the related device_connection is > registered after this probe is called, right? > if not, use IS_ERR_OR_NULL then return PTR_ERR is enough How enough? If return value is NULL it would be transformered to 0, which is success return code from the ->probe() which means we will have ->probed() and not functional device. Am I missing something? -- With Best Regards, Andy Shevchenko
RE: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
> -Original Message-
> From: Shawn Guo
> Sent: 2019年3月4日 14:21
> To: Andy Tang
> Cc: Leo Li ; robh...@kernel.org; mark.rutl...@arm.com;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux...@vger.kernel.org;
> daniel.lezc...@linaro.org; rui.zh...@intel.com; edubez...@gmail.com
> Subject: Re: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
>
> On Mon, Mar 04, 2019 at 11:21:11AM +0800, Yuantian Tang wrote:
> > Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core
> > cluster sensor is used to monitor the temperature of core and SoC
> > platform is for platform. The current dts only support the first sensor.
> > This patch adds the second sensor node to dts to enable it.
> >
> > Signed-off-by: Yuantian Tang
> > ---
> > v2:
> > - Add more information about sensors to description
> > PS: In order to keep consistency to the first thermal-zone node, there
> > will be "WARNING: line over 80 characters" warnings.
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43
> +--
> > 1 files changed, 39 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index 661137f..9f52bc9 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -129,19 +129,19 @@
> > };
> >
> > thermal-zones {
> > - cpu_thermal: cpu-thermal {
> > + ccu {
>
> Is this change really necessary? What does 'ccu' stand for?
I think so. ccu stands for core cluster unit. cpu is too general.
On some platforms, there are more than one core clusters.
At least we should change it to "core cluster" if short form is not appropriate.
>
> > polling-delay-passive = <1000>;
> > polling-delay = <5000>;
> > thermal-sensors = < 0>;
> >
> > trips {
> > - cpu_alert: cpu-alert {
> > + ccu_alert: ccu-alert {
> > temperature = <85000>;
> > hysteresis = <2000>;
> > type = "passive";
> > };
> >
> > - cpu_crit: cpu-crit {
> > + ccu_crit: ccu-crit {
> > temperature = <95000>;
> > hysteresis = <2000>;
> > type = "critical";
> > @@ -150,7 +150,42 @@
> >
> > cooling-maps {
> > map0 {
> > - trip = <_alert>;
> > + trip = <_alert>;
> > + cooling-device =
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> > + };
> > + };
> > + };
> > +
> > + plt {
>
> What about 'platform-thermal' for node name, platform-alert and platform-crit
> for trip nodes below?
OK, will use long name form.
BR,
Andy
>
> Shawn
>
> > + polling-delay-passive = <1000>;
> > + polling-delay = <5000>;
> > + thermal-sensors = < 1>;
> > +
> > + trips {
> > + plt_alert: plt-alert {
> > + temperature = <85000>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > +
> > + plt_crit: plt-crit {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map0 {
> > + trip = <_alert>;
> > cooling-device =
> > < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> > <
Re: [PATCH] x86/uaccess: Remove unused __addr_ok() macro
On Mon, 25 Feb 2019, Joe Perches wrote:
> Looks like it's not used in several arches
>
> $ git grep -w __addr_ok
> arch/arm/include/asm/uaccess.h:#define __addr_ok(addr)
> ((void)(addr), 1)
> arch/csky/include/asm/uaccess.h:#define __addr_ok(addr) (access_ok(addr, 0))
> arch/openrisc/include/asm/uaccess.h:#define __addr_ok(addr) ((unsigned long)
> addr < get_fs())
> arch/sh/include/asm/uaccess.h:#define __addr_ok(addr) \
> arch/sh/include/asm/uaccess.h: __ao_end >= __ao_a && __addr_ok(__ao_end); })
> arch/x86/include/asm/uaccess.h:#define __addr_ok(addr) \
If so, would simly removing it do the trick or is there more magic
involved? I don't have that many cross-compilers though and it's not even
build-tested:
commit f899653c64cce05fde426d0298cd67670f8ab8e2
Author: Christian Kujau
Date: Sun Mar 3 22:43:09 2019 -0800
Remove unused __addr_ok() macro.
arch/arm/include/asm/uaccess.h | 1 -
arch/csky/include/asm/uaccess.h | 2 --
arch/openrisc/include/asm/uaccess.h | 3 ---
arch/sh/include/asm/uaccess.h | 5 +
arch/x86/include/asm/uaccess.h | 2 --
5 files changed, 1 insertion(+), 12 deletions(-)
Signed-off-by: Christian Kujau
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 42aa4a22803c..16411c76076d 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -266,7 +266,6 @@ extern int __put_user_8(void *, unsigned long long);
#define USER_DSKERNEL_DS
#define segment_eq(a, b) (1)
-#define __addr_ok(addr)((void)(addr), 1)
#define __range_ok(addr, size) ((void)(addr), 0)
#define get_fs() (KERNEL_DS)
diff --git a/arch/csky/include/asm/uaccess.h b/arch/csky/include/asm/uaccess.h
index eaa1c3403a42..c02b243fecaa 100644
--- a/arch/csky/include/asm/uaccess.h
+++ b/arch/csky/include/asm/uaccess.h
@@ -24,8 +24,6 @@ static inline int access_ok(const void *addr, unsigned long
size)
((unsigned long)(addr + size) < limit));
}
-#define __addr_ok(addr) (access_ok(addr, 0))
-
extern int __put_user_bad(void);
/*
diff --git a/arch/openrisc/include/asm/uaccess.h
b/arch/openrisc/include/asm/uaccess.h
index a44682c8adc3..9198371e30c2 100644
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -55,9 +55,6 @@
*/
#define __range_ok(addr, size) (size <= get_fs() && addr <= (get_fs()-size))
-/* Ensure that addr is below task's addr_limit */
-#define __addr_ok(addr) ((unsigned long) addr < get_fs())
-
#define access_ok(addr, size) \
({ \
unsigned long __ao_addr = (unsigned long)(addr);\
diff --git a/arch/sh/include/asm/uaccess.h b/arch/sh/include/asm/uaccess.h
index 5fe751ad7582..b41f6a011474 100644
--- a/arch/sh/include/asm/uaccess.h
+++ b/arch/sh/include/asm/uaccess.h
@@ -5,9 +5,6 @@
#include
#include
-#define __addr_ok(addr) \
- ((unsigned long __force)(addr) < current_thread_info()->addr_limit.seg)
-
/*
* __access_ok: Check if address with size is OK or not.
*
@@ -19,7 +16,7 @@
#define __access_ok(addr, size)({ \
unsigned long __ao_a = (addr), __ao_b = (size); \
unsigned long __ao_end = __ao_a + __ao_b - !!__ao_b;\
- __ao_end >= __ao_a && __addr_ok(__ao_end); })
+ __ao_end >= __ao_a; })
#define access_ok(addr, size) \
(__chk_user_ptr(addr), \
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index c133478d..d630978738dc 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -37,8 +37,6 @@ static inline void set_fs(mm_segment_t fs)
#define segment_eq(a, b) ((a).seg == (b).seg)
#define user_addr_max() (current->thread.addr_limit.seg)
-#define __addr_ok(addr)\
- ((unsigned long __force)(addr) < user_addr_max())
/*
* Test whether a block of memory is a valid user space address.
--
BOFH excuse #123:
user to computer ratio too high.
Re: [PATCH v2] RDMA/umem: minor bug fix and cleanup in error handling paths
On Sun, Mar 03, 2019 at 02:37:33PM -0800, John Hubbard wrote:
> On 3/3/19 1:52 AM, Artemy Kovalyov wrote:
> >
> >
> > On 02/03/2019 21:44, Ira Weiny wrote:
> > >
> > > On Sat, Mar 02, 2019 at 12:24:35PM -0800, john.hubb...@gmail.com wrote:
> > > > From: John Hubbard
> > > >
> > > > ...
> > > > 3. Dead code removal: the check for (user_virt & ~page_mask)
> > > > is checking for a condition that can never happen,
> > > > because earlier:
> > > >
> > > > user_virt = user_virt & page_mask;
> > > >
> > > > ...so, remove that entire phrase.
> > > >
> > > > bcnt -= min_t(size_t, npages << PAGE_SHIFT, bcnt);
> > > > mutex_lock(_odp->umem_mutex);
> > > > for (j = 0; j < npages; j++, user_virt += PAGE_SIZE) {
> > > > - if (user_virt & ~page_mask) {
> > > > - p += PAGE_SIZE;
> > > > - if (page_to_phys(local_page_list[j]) != p) {
> > > > - ret = -EFAULT;
> > > > - break;
> > > > - }
> > > > - put_page(local_page_list[j]);
> > > > - continue;
> > > > - }
> > > > -
> > >
> > > I think this is trying to account for compound pages. (ie page_mask could
> > > represent more than PAGE_SIZE which is what user_virt is being
> > > incrimented by.)
> > > But putting the page in that case seems to be the wrong thing to do?
> > >
> > > Yes this was added by Artemy[1] now cc'ed.
> >
> > Right, this is for huge pages, please keep it.
> > put_page() needed to decrement refcount of the head page.
> >
>
> OK, thanks for explaining! Artemy, while you're here, any thoughts about the
> release_pages, and the change of the starting point, from the other part
> of the patch:
Your release pages code is right fix, it will be great if you prepare
proper and standalone patch.
Thanks
>
> @@ -684,9 +677,11 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
> *umem_odp, u64 user_virt,
> mutex_unlock(_odp->umem_mutex);
>
> if (ret < 0) {
> - /* Release left over pages when handling errors. */
> - for (++j; j < npages; ++j)
> - put_page(local_page_list[j]);
> + /*
> + * Release pages, starting at the the first page
> + * that experienced an error.
> + */
> + release_pages(_page_list[j], npages - j);
> break;
> }
> }
>
> ?
>
> thanks,
> --
> John Hubbard
> NVIDIA
>
signature.asc
Description: PGP signature
Re: [f2fs-dev] [PATCH] f2fs: fix to do sanity check with inode.i_inline_xattr_size
Hi Sahitya,
On 2019/3/4 11:59, Sahitya Tummala wrote:
> On Fri, Mar 01, 2019 at 03:38:05PM +0800, Chao Yu wrote:
>> As Paul Bandha reported in bugzilla:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202709
>>
>> When I run the poc on the mounted f2fs img I get a buffer overflow in
>> read_inline_xattr due to there being no sanity check on the value of
>> i_inline_xattr_size.
>>
>> I created the img by just modifying the value of i_inline_xattr_size
>> in the inode:
>>
>> i_name [test1.txt]
>> i_ext: fofs:0 blkaddr:0 len:0
>> i_extra_isize[0x 18 : 24]
>> i_inline_xattr_size [0x : 65535]
>> i_addr[ofs] [0x 0 : 0]
>>
>> mkdir /mnt/f2fs
>> mount ./f2fs1.img /mnt/f2fs
>> gcc poc.c -o poc
>> ./poc
>>
>> int main() {
>> int y = syscall(SYS_listxattr, "/mnt/f2fs/test1.txt", NULL, 0);
>> printf("ret %d", y);
>> printf("errno: %d\n", errno);
>>
>> }
>>
>> BUG: KASAN: slab-out-of-bounds in read_inline_xattr+0x18f/0x260
>> Read of size 262140 at addr 88011035efd8 by task f2fs1poc/3263
>>
>> CPU: 0 PID: 3263 Comm: f2fs1poc Not tainted 4.18.0-custom #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
>> Call Trace:
>> dump_stack+0x71/0xab
>> print_address_description+0x83/0x250
>> kasan_report+0x213/0x350
>> memcpy+0x1f/0x50
>> read_inline_xattr+0x18f/0x260
>> read_all_xattrs+0xba/0x190
>> f2fs_listxattr+0x9d/0x3f0
>> listxattr+0xb2/0xd0
>> path_listxattr+0x93/0xe0
>> do_syscall_64+0x9d/0x220
>> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>
>> Let's add sanity check for inode.i_inline_xattr_size during f2fs_iget()
>> to avoid this issue.
>>
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/inode.c | 14 ++
>> fs/f2fs/super.c | 7 ++-
>> fs/f2fs/xattr.h | 9 +
>> 3 files changed, 25 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
>> index bec52961630b..b132fe2ff779 100644
>> --- a/fs/f2fs/inode.c
>> +++ b/fs/f2fs/inode.c
>> @@ -14,6 +14,7 @@
>> #include "f2fs.h"
>> #include "node.h"
>> #include "segment.h"
>> +#include "xattr.h"
>>
>> #include
>>
>> @@ -248,6 +249,19 @@ static bool sanity_check_inode(struct inode *inode,
>> struct page *node_page)
>> return false;
>> }
>>
>> +if (f2fs_has_extra_attr(inode) &&
>> +f2fs_sb_has_flexible_inline_xattr(sbi) &&
>> +(fi->i_inline_xattr_size < MIN_INLINE_XATTR_SIZE ||
>> +fi->i_inline_xattr_size > MAX_INLINE_XATTR_SIZE)) {
>> +set_sbi_flag(sbi, SBI_NEED_FSCK);
>> +f2fs_msg(sbi->sb, KERN_WARNING,
>> +"%s: inode (ino=%lx) has corrupted "
>> +"i_inline_xattr_size: %d, min: %zu, max: %zu",
>> +__func__, inode->i_ino, fi->i_inline_xattr_size,
>> +MIN_INLINE_XATTR_SIZE, MAX_INLINE_XATTR_SIZE);
>> +return false;
>> +}
>> +
>> if (F2FS_I(inode)->extent_tree) {
>> struct extent_info *ei = _I(inode)->extent_tree->largest;
>>
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>> index 42eb5c86330a..9184b7524c03 100644
>> --- a/fs/f2fs/super.c
>> +++ b/fs/f2fs/super.c
>> @@ -835,12 +835,9 @@ static int parse_options(struct super_block *sb, char
>> *options)
>> return -EINVAL;
>> }
>> if (F2FS_OPTION(sbi).inline_xattr_size <
>> -sizeof(struct f2fs_xattr_header) / sizeof(__le32) ||
>> +MIN_INLINE_XATTR_SIZE ||
>> F2FS_OPTION(sbi).inline_xattr_size >
>> -DEF_ADDRS_PER_INODE -
>> -F2FS_TOTAL_EXTRA_ATTR_SIZE / sizeof(__le32) -
>> -DEF_INLINE_RESERVED_SIZE -
>> -MIN_INLINE_DENTRY_SIZE / sizeof(__le32)) {
>> +MAX_INLINE_XATTR_SIZE) {
>> f2fs_msg(sb, KERN_ERR,
>> "inline xattr size is out of range");
>> return -EINVAL;
>> diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
>> index 67db134da0f5..94e8a5eeaae1 100644
>> --- a/fs/f2fs/xattr.h
>> +++ b/fs/f2fs/xattr.h
>> @@ -55,6 +55,8 @@ struct f2fs_xattr_entry {
>> #define XATTR_FIRST_ENTRY(ptr) (XATTR_ENTRY(XATTR_HDR(ptr) + 1))
>> #define XATTR_ROUND (3)
>>
>> +#define XATTR_HDR_SIZE (sizeof(struct f2fs_xattr_header))
>> +
>> #define XATTR_ALIGN(size) (((size) + XATTR_ROUND) & ~XATTR_ROUND)
>>
>> #define ENTRY_SIZE(entry) (XATTR_ALIGN(sizeof(struct f2fs_xattr_entry) + \
>> @@ -78,6 +80,13 @@ struct f2fs_xattr_entry {
>> sizeof(struct f2fs_xattr_header) - \
>> sizeof(struct f2fs_xattr_entry))
>>
>> +#define MAX_INLINE_XATTR_SIZE
Re: [RFC PATCH v1 00/25] printk: new implementation
Hi John, On (02/13/19 14:43), John Ogness wrote: > Hi Sergey, > > I am glad to see that you are getting involved here. Your previous > talks, work, and discussions were a large part of my research when > preparing for this work. YAYY! Thanks! That's a pretty massive research and a patch set! [..] > If we are talking about an SMP system where logbuf_lock is locked, the > call chain is actually: > > panic() > crash_smp_send_stop() > ... wait for "num_online_cpus() == 1" ... > printk_safe_flush_on_panic(); > console_flush_on_panic(); > > Is it guaranteed that the kernel will successfully stop the other CPUs > so that it can print to the console? Right. By the way, this reminds that I sort of wanted to send a patch which would unconditionally raw_spin_lock_init(_lock) (without the num_online_cpus() check) in printk_safe_flush_on_panic(). > And then there is console_flush_on_panic(), which will ignore locks and > write to the consoles, expecting them to check "oops_in_progress" and > ignore their own internal locks. > > Is it guaranteed that locks can just be ignored and backtraces will be > seen and legible to the user? That's a tricky question. In the same way we may have no guarantees that all consoles can sport ->atomic() write API. And then have no guarantees that every system will have ->atomic consoles. > > Do you see large latencies because of logbuf spinlock? > [..] > > For slow consoles, this can cause large latencies for some misfortunate > tasks. Yes, makes sense. > > One thing that I have learned is that preemptible printk does not work > > as expected; it wants to be 'atomic' and just stay busy as long as it > > can. > > We tried preemptible printk at Samsung and the result was just bad: > >preempted printk kthread + slow serial console = lots of lost > > messages > > As long as all critical messages are print directly and immediately to > an emergency console, why is it is problem if the informational messages > to consoles are sometimes delayed or lost? And if those informational > messages _are_ so important, there are things the user can do. For > example, create a realtime userspace task to read /dev/kmsg. > > > We also had preemptile printk in the upstream kernel and reverted the > > patch (see fd5f7cde1b85d4c8e09); same reasons - we had reports that > > preemptible printk could "stall" for minutes. > > But in this case the preemptible task was used for printing critical > tasks as well. Then the stall really is a problem. I am proposing to > rely on emergency consoles for critical messages. By changing printk to > support 2 different channels (emergency and non-emergency), we can focus > on making each of those channels optimal. Right. Assuming that we always have at least one ->atomic channel we can prioritize (and sacrifice !atomic channels, etc.). People, sort of, already can prioritize some channels; IIRC, netcon can be configured to print messages only when oops_in_progress and to drop messages otherwise. Things can get different if ->atomic channel is not available. -ss
Re: [PATCH v2] f2fs: fix to check inline_xattr_size boundary correctly
Hi Jaegeuk, On 2019/2/15 0:08, Chao Yu wrote: > --- > v2: > - fix lower bound check, inline xattr size should be larger than > xattr_header's size at least. ... > + if (F2FS_OPTION(sbi).inline_xattr_size < > + sizeof(struct f2fs_xattr_header) / sizeof(__le32) No sure we should set this low bound as above... now I guess original non-zero check is enough. How do you think of setting inline_xattr_size range as (0, MAX_INLINE_XATTR_SIZE]? Thanks,
RE: [PATCH 11/12] percpu: convert chunk hints to be based on pcpu_block_md
> -Original Message-
> From: Dennis Zhou [mailto:den...@kernel.org]
> Sent: 2019年3月4日 4:22
> To: Peng Fan
> Cc: Dennis Zhou ; Tejun Heo ; Christoph
> Lameter ; Vlad Buslov ;
> kernel-t...@fb.com; linux...@kvack.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 11/12] percpu: convert chunk hints to be based on
> pcpu_block_md
>
> On Sun, Mar 03, 2019 at 08:18:49AM +, Peng Fan wrote:
> >
> >
> > > -Original Message-
> > > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org]
> On
> > > Behalf Of Dennis Zhou
> > > Sent: 2019年2月28日 10:19
> > > To: Dennis Zhou ; Tejun Heo ;
> > > Christoph Lameter
> > > Cc: Vlad Buslov ; kernel-t...@fb.com;
> > > linux...@kvack.org; linux-kernel@vger.kernel.org
> > > Subject: [PATCH 11/12] percpu: convert chunk hints to be based on
> > > pcpu_block_md
> > >
> > > As mentioned in the last patch, a chunk's hints are no different
> > > than a block just responsible for more bits. This converts chunk
> > > level hints to use a pcpu_block_md to maintain them. This lets us
> > > reuse the same hint helper functions as a block. The left_free and
> > > right_free are unused by the chunk's pcpu_block_md.
> > >
> > > Signed-off-by: Dennis Zhou
> > > ---
> > > mm/percpu-internal.h | 5 +-
> > > mm/percpu-stats.c| 5 +-
> > > mm/percpu.c | 120
> +++
> > > 3 files changed, 57 insertions(+), 73 deletions(-)
> > >
> > > diff --git a/mm/percpu-internal.h b/mm/percpu-internal.h index
> > > 119bd1119aa7..0468ba500bd4 100644
> > > --- a/mm/percpu-internal.h
> > > +++ b/mm/percpu-internal.h
> > > @@ -39,9 +39,7 @@ struct pcpu_chunk {
> > >
> > > struct list_headlist; /* linked to pcpu_slot lists */
> > > int free_bytes; /* free bytes in the chunk */
> > > - int contig_bits;/* max contiguous size hint */
> > > - int contig_bits_start; /* contig_bits starting
> > > - offset */
> > > + struct pcpu_block_mdchunk_md;
> > > void*base_addr; /* base address of this chunk */
> > >
> > > unsigned long *alloc_map; /* allocation map */
> > > @@ -49,7 +47,6 @@ struct pcpu_chunk {
> > > struct pcpu_block_md*md_blocks; /* metadata blocks */
> > >
> > > void*data; /* chunk data */
> > > - int first_bit; /* no free below this */
> > > boolimmutable; /* no [de]population allowed */
> > > int start_offset; /* the overlap with the previous
> > > region to have a page
> > > aligned diff --git
> > > a/mm/percpu-stats.c b/mm/percpu-stats.c index
> > > b5fdd43b60c9..ef5034a0464e 100644
> > > --- a/mm/percpu-stats.c
> > > +++ b/mm/percpu-stats.c
> > > @@ -53,6 +53,7 @@ static int find_max_nr_alloc(void) static void
> > > chunk_map_stats(struct seq_file *m, struct pcpu_chunk *chunk,
> > > int *buffer)
> > > {
> > > + struct pcpu_block_md *chunk_md = >chunk_md;
> > > int i, last_alloc, as_len, start, end;
> > > int *alloc_sizes, *p;
> > > /* statistics */
> > > @@ -121,9 +122,9 @@ static void chunk_map_stats(struct seq_file *m,
> > > struct pcpu_chunk *chunk,
> > > P("nr_alloc", chunk->nr_alloc);
> > > P("max_alloc_size", chunk->max_alloc_size);
> > > P("empty_pop_pages", chunk->nr_empty_pop_pages);
> > > - P("first_bit", chunk->first_bit);
> > > + P("first_bit", chunk_md->first_free);
> > > P("free_bytes", chunk->free_bytes);
> > > - P("contig_bytes", chunk->contig_bits * PCPU_MIN_ALLOC_SIZE);
> > > + P("contig_bytes", chunk_md->contig_hint *
> PCPU_MIN_ALLOC_SIZE);
> > > P("sum_frag", sum_frag);
> > > P("max_frag", max_frag);
> > > P("cur_min_alloc", cur_min_alloc); diff --git a/mm/percpu.c
> > > b/mm/percpu.c index 7cdf14c242de..197479f2c489 100644
> > > --- a/mm/percpu.c
> > > +++ b/mm/percpu.c
> > > @@ -233,10 +233,13 @@ static int pcpu_size_to_slot(int size)
> > >
> > > static int pcpu_chunk_slot(const struct pcpu_chunk *chunk) {
> > > - if (chunk->free_bytes < PCPU_MIN_ALLOC_SIZE || chunk->contig_bits
> > > == 0)
> > > + const struct pcpu_block_md *chunk_md = >chunk_md;
> > > +
> > > + if (chunk->free_bytes < PCPU_MIN_ALLOC_SIZE ||
> > > + chunk_md->contig_hint == 0)
> > > return 0;
> > >
> > > - return pcpu_size_to_slot(chunk->contig_bits * PCPU_MIN_ALLOC_SIZE);
> > > + return pcpu_size_to_slot(chunk_md->contig_hint *
> > > PCPU_MIN_ALLOC_SIZE);
> > > }
> > >
> > > /* set the pointer to a chunk in a page struct */ @@ -592,54 +595,6
> > > @@ static inline bool pcpu_region_overlap(int a, int b, int x, int y)
> > > return false;
> > > }
> > >
> > > -/**
> > > - * pcpu_chunk_update - updates the chunk metadata given a free area
> > > - * @chunk: chunk of interest
> > > - * @bit_off: chunk offset
> > > - * @bits: size
Re: [PATCH][next] RDMA/nes: remove redundant check on udata
On Sat, Mar 02, 2019 at 11:06:36PM +, Colin King wrote:
> From: Colin Ian King
>
> The non-null check on udata is redundant as this check was performed
> just a few statements earlier and the check is always true as udata
> must be non-null at this point. Remove redundant the check on udata
> and the redundant else part that can never be executed.
>
> Detected by CoverityScan, CID#1477317 ("Logically dead code")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/nes/nes_verbs.c | 73 +--
> 1 file changed, 34 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/infiniband/hw/nes/nes_verbs.c
> b/drivers/infiniband/hw/nes/nes_verbs.c
> index 828e4af3f951..526092d435df 100644
> --- a/drivers/infiniband/hw/nes/nes_verbs.c
> +++ b/drivers/infiniband/hw/nes/nes_verbs.c
> @@ -1039,53 +1039,48 @@ static struct ib_qp *nes_create_qp(struct ib_pd *ibpd,
> }
> if (req.user_qp_buffer)
> nesqp->nesuqp_addr = req.user_qp_buffer;
> - if (udata) {
> - nesqp->user_mode = 1;
It was single place where user_mode was set, you should continue and
remove all code which depends on "if (nesqp->user_mode)".
I looked on the change which triggered Coverity warning and looks like
your commit message should include this Fixes line:
Fixes: 899444505473 ("IB/{hw,sw}: Remove 'uobject->context' dependency in
object creation APIs")
Thanks
signature.asc
Description: PGP signature
Re: [PATCH] drm/amdgpu/powerplay: Fix missing break in switch statement
On Fri, Mar 01, 2019 at 03:29:43PM -0600, Gustavo A. R. Silva wrote:
> Add missing break statement in order to prevent the code from falling
> through to case SMU_Discrete_DpmTable.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 34a564eaf528 ("drm/amd/powerplay: implement fw image related smum
> interface for Polaris.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> index 52abca065764..222fb79d319e 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> @@ -2330,6 +2330,7 @@ static uint32_t polaris10_get_offsetof(uint32_t type,
> uint32_t member)
> case DRAM_LOG_BUFF_SIZE:
> return offsetof(SMU74_SoftRegisters,
> DRAM_LOG_BUFF_SIZE);
> }
> + break;
> case SMU_Discrete_DpmTable:
> switch (member) {
> case UvdBootLevel:
> --
> 2.21.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v4] f2fs: add bio cache for IPU
On 2019/3/2 1:55, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> Ping,
>
> Ditto.
Copied.
Thanks,
>
>>
>> On 2019/2/19 16:15, Chao Yu wrote:
>>> SQLite in Wal mode may trigger sequential IPU write in db-wal file, after
>>> commit d1b3e72d5490 ("f2fs: submit bio of in-place-update pages"), we
>>> lost the chance of merging page in inner managed bio cache, result in
>>> submitting more small-sized IO.
>>>
>>> So let's add temporary bio in writepages() to cache mergeable write IO as
>>> much as possible.
>>>
>>> Test case:
>>> 1. xfs_io -f /mnt/f2fs/file -c "pwrite 0 65536" -c "fsync"
>>> 2. xfs_io -f /mnt/f2fs/file -c "pwrite 0 65536" -c "fsync"
>>>
>>> Before:
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65544, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65552, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65560, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65568, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65576, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65584, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65592, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65600, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65608, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65616, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65624, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65632, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65640, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65648, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65656, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65664, size = 4096
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), NODE, sector =
>>> 57352, size = 4096
>>>
>>> After:
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
>>> 65544, size = 65536
>>> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), NODE, sector =
>>> 57368, size = 4096
>>>
>>> Signed-off-by: Chao Yu
>>> ---
>>> v4:
>>> - fix to set *bio to NULL in f2fs_submit_ipu_bio()
>>> - spread f2fs_submit_ipu_bio()
>>> - fix to count dirty encrypted page correctly in f2fs_merge_page_bio()
>>> - remove redundant assignment of fio->last_block
>>> fs/f2fs/data.c| 88 ++-
>>> fs/f2fs/f2fs.h| 3 ++
>>> fs/f2fs/segment.c | 5 ++-
>>> 3 files changed, 86 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 35910ff23582..e4c183e85de8 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -296,20 +296,20 @@ static void __submit_merged_bio(struct f2fs_bio_info
>>> *io)
>>> io->bio = NULL;
>>> }
>>>
>>> -static bool __has_merged_page(struct f2fs_bio_info *io, struct inode
>>> *inode,
>>> +static bool __has_merged_page(struct bio *bio, struct inode *inode,
>>> struct page *page, nid_t ino)
>>> {
>>> struct bio_vec *bvec;
>>> struct page *target;
>>> int i;
>>>
>>> - if (!io->bio)
>>> + if (!bio)
>>> return false;
>>>
>>> if (!inode && !page && !ino)
>>> return true;
>>>
>>> - bio_for_each_segment_all(bvec, io->bio, i) {
>>> + bio_for_each_segment_all(bvec, bio, i) {
>>>
>>> if (bvec->bv_page->mapping)
>>> target = bvec->bv_page;
>>> @@ -360,7 +360,7 @@ static void __submit_merged_write_cond(struct
>>> f2fs_sb_info *sbi,
>>> struct f2fs_bio_info *io = sbi->write_io[btype] + temp;
>>>
>>> down_read(>io_rwsem);
>>> - ret = __has_merged_page(io, inode, page, ino);
>>> + ret = __has_merged_page(io->bio, inode, page, ino);
>>> up_read(>io_rwsem);
>>> }
>>> if (ret)
>>> @@ -429,6 +429,61 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>>> return 0;
>>> }
>>>
>>> +int f2fs_merge_page_bio(struct f2fs_io_info *fio)
>>> +{
>>> + struct bio *bio = *fio->bio;
>>> + struct page *page = fio->encrypted_page ?
>>> + fio->encrypted_page : fio->page;
>>> +
>>> + if (!f2fs_is_valid_blkaddr(fio->sbi, fio->new_blkaddr,
>>> + __is_meta_io(fio) ? META_GENERIC : DATA_GENERIC))
>>> +
Re: [PATCH v3] f2fs: rebuild nat_bits during umount
On 2019/3/2 1:55, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> Ping,
>>
>> Could you please try this new version?
>
> It's in the queue, and I'll test this after the next pull request.
Okay. :)
Thanks,
>
>>
>> On 2019/2/17 6:26, Chao Yu wrote:
>>> From: Chao Yu
>>>
>>> If all free_nat_bitmap are available, we can rebuild nat_bits from
>>> free_nat_bitmap entirely during umount, let's make another chance
>>> to reenable nat_bits for image.
>>>
>>> Signed-off-by: Chao Yu
>>> ---
>>> v3:
>>> - fix to remove nat journal during umount.
>>> fs/f2fs/checkpoint.c | 23 +
>>> fs/f2fs/f2fs.h | 29 ++--
>>> fs/f2fs/node.c | 82 +---
>>> 3 files changed, 89 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index 10a3ada28715..b4c9de4e6eb0 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -1225,12 +1225,22 @@ static void update_ckpt_flags(struct f2fs_sb_info
>>> *sbi, struct cp_control *cpc)
>>> struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
>>> unsigned long flags;
>>>
>>> - spin_lock_irqsave(>cp_lock, flags);
>>> + if (cpc->reason & CP_UMOUNT) {
>>> + if (le32_to_cpu(ckpt->cp_pack_total_block_count) >
>>> + sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks) {
>>> + clear_ckpt_flags(sbi, CP_NAT_BITS_FLAG);
>>> + f2fs_msg(sbi->sb, KERN_NOTICE,
>>> + "Disable nat_bits due to no space");
>>> + } else if (!is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG) &&
>>> + f2fs_nat_bitmap_enabled(sbi)) {
>>> + f2fs_enable_nat_bits(sbi);
>>> + set_ckpt_flags(sbi, CP_NAT_BITS_FLAG);
>>> + f2fs_msg(sbi->sb, KERN_NOTICE,
>>> + "Rebuild and enable nat_bits");
>>> + }
>>> + }
>>>
>>> - if ((cpc->reason & CP_UMOUNT) &&
>>> - le32_to_cpu(ckpt->cp_pack_total_block_count) >
>>> - sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks)
>>> - disable_nat_bits(sbi, false);
>>> + spin_lock_irqsave(>cp_lock, flags);
>>>
>>> if (cpc->reason & CP_TRIMMED)
>>> __set_ckpt_flags(ckpt, CP_TRIMMED_FLAG);
>>> @@ -1395,7 +1405,8 @@ static int do_checkpoint(struct f2fs_sb_info *sbi,
>>> struct cp_control *cpc)
>>> start_blk = __start_cp_next_addr(sbi);
>>>
>>> /* write nat bits */
>>> - if (enabled_nat_bits(sbi, cpc)) {
>>> + if ((cpc->reason & CP_UMOUNT) &&
>>> + is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG)) {
>>> __u64 cp_ver = cur_cp_version(ckpt);
>>> block_t blk;
>>>
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index c0d30810ef8a..a543354fc6bf 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -1615,33 +1615,6 @@ static inline void clear_ckpt_flags(struct
>>> f2fs_sb_info *sbi, unsigned int f)
>>> spin_unlock_irqrestore(>cp_lock, flags);
>>> }
>>>
>>> -static inline void disable_nat_bits(struct f2fs_sb_info *sbi, bool lock)
>>> -{
>>> - unsigned long flags;
>>> -
>>> - /*
>>> -* In order to re-enable nat_bits we need to call fsck.f2fs by
>>> -* set_sbi_flag(sbi, SBI_NEED_FSCK). But it may give huge cost,
>>> -* so let's rely on regular fsck or unclean shutdown.
>>> -*/
>>> -
>>> - if (lock)
>>> - spin_lock_irqsave(>cp_lock, flags);
>>> - __clear_ckpt_flags(F2FS_CKPT(sbi), CP_NAT_BITS_FLAG);
>>> - kvfree(NM_I(sbi)->nat_bits);
>>> - NM_I(sbi)->nat_bits = NULL;
>>> - if (lock)
>>> - spin_unlock_irqrestore(>cp_lock, flags);
>>> -}
>>> -
>>> -static inline bool enabled_nat_bits(struct f2fs_sb_info *sbi,
>>> - struct cp_control *cpc)
>>> -{
>>> - bool set = is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG);
>>> -
>>> - return (cpc) ? (cpc->reason & CP_UMOUNT) && set : set;
>>> -}
>>> -
>>> static inline void f2fs_lock_op(struct f2fs_sb_info *sbi)
>>> {
>>> down_read(>cp_rwsem);
>>> @@ -2970,6 +2943,7 @@ int f2fs_truncate_inode_blocks(struct inode *inode,
>>> pgoff_t from);
>>> int f2fs_truncate_xattr_node(struct inode *inode);
>>> int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi,
>>> unsigned int seq_id);
>>> +bool f2fs_nat_bitmap_enabled(struct f2fs_sb_info *sbi);
>>> int f2fs_remove_inode_page(struct inode *inode);
>>> struct page *f2fs_new_inode_page(struct inode *inode);
>>> struct page *f2fs_new_node_page(struct dnode_of_data *dn, unsigned int
>>> ofs);
>>> @@ -2993,6 +2967,7 @@ int f2fs_recover_xattr_data(struct inode *inode,
>>> struct page *page);
>>> int f2fs_recover_inode_page(struct f2fs_sb_info *sbi, struct page *page);
>>> int f2fs_restore_node_summary(struct f2fs_sb_info *sbi,
>>> unsigned int segno, struct f2fs_summary_block *sum);
>>>
RE: [PATCH] RDMA/cma: Make CM response timeout and # CM retries configurable
> -Original Message-
> From: Leon Romanovsky
> Sent: Saturday, February 23, 2019 2:50 AM
> To: Doug Ledford
> Cc: Steve Wise ; Jason Gunthorpe
> ; Håkon Bugge ; Parav Pandit
> ; linux-r...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] RDMA/cma: Make CM response timeout and # CM
> retries configurable
>
> On Fri, Feb 22, 2019 at 12:51:55PM -0500, Doug Ledford wrote:
> >
> >
> > > On Feb 22, 2019, at 12:14 PM, Steve Wise
> wrote:
> > >
> > >
> > > On 2/22/2019 10:36 AM, Jason Gunthorpe wrote:
> > >> On Sun, Feb 17, 2019 at 06:09:09PM +0100, Håkon Bugge wrote:
> > >>> During certain workloads, the default CM response timeout is too
> > >>> short, leading to excessive retries. Hence, make it configurable
> > >>> through sysctl. While at it, also make number of CM retries
> > >>> configurable.
> > >>>
> > >>> The defaults are not changed.
> > >>>
> > >>> Signed-off-by: Håkon Bugge
> > >>> drivers/infiniband/core/cma.c | 51
> > >>> ++-
> > >>> 1 file changed, 44 insertions(+), 7 deletions(-)
> > >>>
> > >>> diff --git a/drivers/infiniband/core/cma.c
> > >>> b/drivers/infiniband/core/cma.c index c43512752b8a..ce99e1cd1029
> > >>> 100644
> > >>> +++ b/drivers/infiniband/core/cma.c
> > >>> @@ -43,6 +43,7 @@
> > >>> #include
> > >>> #include
> > >>> #include
> > >>> +#include
> > >>> #include
> > >>>
> > >>> #include
> > >>> @@ -68,13 +69,46 @@ MODULE_AUTHOR("Sean Hefty");
> > >>> MODULE_DESCRIPTION("Generic RDMA CM Agent");
> MODULE_LICENSE("Dual
> > >>> BSD/GPL");
> > >>>
> > >>> -#define CMA_CM_RESPONSE_TIMEOUT 20 #define
> > >>> CMA_QUERY_CLASSPORT_INFO_TIMEOUT 3000 -#define
> CMA_MAX_CM_RETRIES
> > >>> 15 #define CMA_CM_MRA_SETTING (IB_CM_MRA_FLAG_DELAY | 24)
> #define
> > >>> CMA_IBOE_PACKET_LIFETIME 18 #define
> CMA_PREFERRED_ROCE_GID_TYPE
> > >>> IB_GID_TYPE_ROCE_UDP_ENCAP
> > >>>
> > >>> +#define CMA_DFLT_CM_RESPONSE_TIMEOUT 20 static int
> > >>> +cma_cm_response_timeout = CMA_DFLT_CM_RESPONSE_TIMEOUT;
> static
> > >>> +int cma_cm_response_timeout_min = 8; static int
> > >>> +cma_cm_response_timeout_max = 31; #undef
> > >>> +CMA_DFLT_CM_RESPONSE_TIMEOUT
> > >>> +
> > >>> +#define CMA_DFLT_MAX_CM_RETRIES 15 static int
> cma_max_cm_retries
> > >>> += CMA_DFLT_MAX_CM_RETRIES; static int cma_max_cm_retries_min
> = 1;
> > >>> +static int cma_max_cm_retries_max = 100; #undef
> > >>> +CMA_DFLT_MAX_CM_RETRIES
> > >>> +
> > >>> +static struct ctl_table_header *cma_ctl_table_hdr; static struct
> > >>> +ctl_table cma_ctl_table[] = {
> > >>> + {
> > >>> + .procname = "cma_cm_response_timeout",
> > >>> + .data = _cm_response_timeout,
> > >>> + .maxlen = sizeof(cma_cm_response_timeout),
> > >>> + .mode = 0644,
> > >>> + .proc_handler = proc_dointvec_minmax,
> > >>> + .extra1 = _cm_response_timeout_min,
> > >>> + .extra2 = _cm_response_timeout_max,
> > >>> + },
> > >>> + {
> > >>> + .procname = "cma_max_cm_retries",
> > >>> + .data = _max_cm_retries,
> > >>> + .maxlen = sizeof(cma_max_cm_retries),
> > >>> + .mode = 0644,
> > >>> + .proc_handler = proc_dointvec_minmax,
> > >>> + .extra1 = _max_cm_retries_min,
> > >>> + .extra2 = _max_cm_retries_max,
> > >>> + },
> > >>> + { }
> > >>> +};
> > >> Is sysctl the right approach here? Should it be rdma tool instead?
> > >>
> > >> Jason
> > >
> > > There are other rdma sysctls currently: net.rdma_ucm.max_backlog
> > > and net.iw_cm.default_backlog. The core network stack seems to use
> > > sysctl and not ip tool to set basically globals.
> > >
> > > To use rdma tool, we'd have to have some concept of a "module"
> > > object, I guess. IE there's dev, link, and resource rdma tool objects
> currently.
> > > But these cma timeout settings are really not per dev, link, nor a
> > > resource. Maybe we have just a "core" object: rdma core set
> > > cma_max_cm_retries min 8 max 30.
> >
> > I don’t know, I think you make a fairly good argument for leaving it as a
> sysctl. We have infrastructure in place for admins to set persistent sysctl
> settings. The per device/link settings need something different because link
> names and such can change. Since these are globals, I’d leave them where
> they are.
> >
>
> I have patches from Parav which extend rdmatool to set global to whole
> stack parameters, something like "rdma system ...", so the option to set
> through rdmatool global parameters for modules e.g. "rdma system cma set
> ..."
> exists. But I'm not sure if it is right thing to do.
>
I think we should use rdma_nl_register(RDMA_NL_RDMA_CM, cma_cb_table) which was
removed as part of ID stats removal.
Because of below reasons.
1. rdma netlink command auto loads the module
Re: [PATCH][next] net/mlx5e: Remove redundant assignment
On Sun, Mar 03, 2019 at 03:20:57PM +, Roi Dayan wrote:
>
>
> On 02/03/2019 21:39, Gustavo A. R. Silva wrote:
> > Remove redundant assignment to tun_entropy->enabled.
> >
> > Addesses-Coverity-ID: 1477328 ("Unused value")
> > Fixes: 97417f6182f8 ("net/mlx5e: Fix GRE key by controlling port tunnel
> > entropy calculation")
>
> the commit doesn't fix any real issue but is more of a cleanup.
> so I'm not sure if fixes line is relevant or not.
> beside that looks ok.
It doesn't matter if it is real issue or not, the code is wrong and
should be fixed. This alone is enough to see the Fixes line.
Thanks,
Acked-by: Leon Romanovsky
signature.asc
Description: PGP signature
Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
On Mon, Mar 04, 2019 at 02:08:54AM +, jacky@sony.com wrote: > > > This email is confidential and intended only for the use of the individual or > entity named above and may contain information that is privileged. If you are > not the intended recipient, you are notified that any dissemination, > distribution or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by return email or > telephone and destroy the original message. - This mail is sent via Sony Asia > Pacific Mail Gateway.. This footer requires me to delete this email as it is not compatible with doing Linux kernel development. greg k-h
Re: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
On Mon, Mar 04, 2019 at 11:21:11AM +0800, Yuantian Tang wrote:
> Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core cluster
> sensor is used to monitor the temperature of core and SoC platform is for
> platform. The current dts only support the first sensor.
> This patch adds the second sensor node to dts to enable it.
>
> Signed-off-by: Yuantian Tang
> ---
> v2:
> - Add more information about sensors to description
> PS: In order to keep consistency to the first thermal-zone node, there will
> be "WARNING: line over 80 characters" warnings.
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43 +--
> 1 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 661137f..9f52bc9 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -129,19 +129,19 @@
> };
>
> thermal-zones {
> - cpu_thermal: cpu-thermal {
> + ccu {
Is this change really necessary? What does 'ccu' stand for?
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 0>;
>
> trips {
> - cpu_alert: cpu-alert {
> + ccu_alert: ccu-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - cpu_crit: cpu-crit {
> + ccu_crit: ccu-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> @@ -150,7 +150,42 @@
>
> cooling-maps {
> map0 {
> - trip = <_alert>;
> + trip = <_alert>;
> + cooling-device =
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +
> + plt {
What about 'platform-thermal' for node name, platform-alert and
platform-crit for trip nodes below?
Shawn
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 1>;
> +
> + trips {
> + plt_alert: plt-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + plt_crit: plt-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> --
> 1.7.1
>
Re: [PATCH 01/20] docs/zh_CN: add disclaimer file
BTW, Corbet, Some of email address are unused and zh-kernel.org web site are unused and on sale. That are: TripleX Chung 李阳 Li Yang Zhang Wei Do we need to remove them in kernel doc and MAINTAINERS? Or remove but get a word for credit? Thanks Alex On 2019/3/4 11:57 上午, Alex Shi wrote: > This a disclaimer file which will be included in Chinese files > as header. To reduce the same common contents copy. > > Most of contents quoted from Federico Vaga's file: > Documentation/translations/it_IT/disclaimer-ita.rst. > Thanks a lot! > > Signed-off-by: Alex Shi > Cc: Harry Wei > Cc: Jonathan Corbet > Cc: Li Zefan > Cc: Shawn Guo > Cc: Fengguang Wu > Cc: Coly Li > Cc: Federico Vaga > --- > Documentation/translations/zh_CN/disclaimer-zh_CN.rst | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 Documentation/translations/zh_CN/disclaimer-zh_CN.rst > > diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst > b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst > new file mode 100644 > index ..0de5dfb069ca > --- /dev/null > +++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst > @@ -0,0 +1,11 @@ > +:orphan: > + > +.. warning:: > + The purpose of this file is to be easier to read and understand for > Chinese > + speakers and is not intended as a fork. So, if you have any comments or > + updates for this file please try to update the original English file > first. > + > +.. note:: > + If you find any difference between this document and the original file or > a > + problem with the translation, please contact the maintainer of this file, > + or get help from Alex Shi
Re: [PATCH] ARM: imx_v6_v7_defconfig: Add GPIO_PCF857X
On Sun, Mar 03, 2019 at 08:32:30PM -0600, Adam Ford wrote: > The imx6q-logicpd board has a PCF8575 connected to it, so this > patch turns it on my default now. > > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH v4] mm/hugetlb: Fix unsigned overflow in __nr_hugepages_store_common()
On Tue, Feb 26, 2019 at 11:32:24AM -0800, Mike Kravetz wrote:
> On 2/25/19 10:21 PM, David Rientjes wrote:
> > On Tue, 26 Feb 2019, Jing Xiangfeng wrote:
> >> On 2019/2/26 3:17, David Rientjes wrote:
> >>> On Mon, 25 Feb 2019, Mike Kravetz wrote:
> >>>
> Ok, what about just moving the calculation/check inside the lock as in
> the
> untested patch below?
>
> Signed-off-by: Mike Kravetz
>
>
>
> >>>
> >>> Looks good; Jing, could you test that this fixes your case?
> >>
> >> Yes, I have tested this patch, it can also fix my case.
> >
> > Great!
> >
> > Reported-by: Jing Xiangfeng
> > Tested-by: Jing Xiangfeng
> > Acked-by: David Rientjes
>
> Thanks Jing and David!
>
> Here is the patch with an updated commit message and above tags:
>
> From: Mike Kravetz
> Date: Tue, 26 Feb 2019 10:43:24 -0800
> Subject: [PATCH] hugetlbfs: fix potential over/underflow setting node specific
> nr_hugepages
>
> The number of node specific huge pages can be set via a file such as:
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> When a node specific value is specified, the global number of huge
> pages must also be adjusted. This adjustment is calculated as the
> specified node specific value + (global value - current node value).
> If the node specific value provided by the user is large enough, this
> calculation could overflow an unsigned long leading to a smaller
> than expected number of huge pages.
>
> To fix, check the calculation for overflow. If overflow is detected,
> use ULONG_MAX as the requested value. This is inline with the user
> request to allocate as many huge pages as possible.
>
> It was also noticed that the above calculation was done outside the
> hugetlb_lock. Therefore, the values could be inconsistent and result
> in underflow. To fix, the calculation is moved to within the routine
> set_max_huge_pages() where the lock is held.
>
> Reported-by: Jing Xiangfeng
> Signed-off-by: Mike Kravetz
> Tested-by: Jing Xiangfeng
> Acked-by: David Rientjes
Looks good to me with improved comments.
Thanks everyone.
Reviewed-by: Naoya Horiguchi
> ---
> mm/hugetlb.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index b37e3100b7cc..a7e4223d2df5 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2274,7 +2274,7 @@ static int adjust_pool_surplus(struct hstate *h,
> nodemask_t *nodes_allowed,
> }
>
> #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> -static int set_max_huge_pages(struct hstate *h, unsigned long count,
> +static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
> nodemask_t *nodes_allowed)
> {
> unsigned long min_count, ret;
> @@ -2289,6 +2289,23 @@ static int set_max_huge_pages(struct hstate *h,
> unsigned
> long count,
> goto decrease_pool;
> }
>
> + spin_lock(_lock);
> +
> + /*
> + * Check for a node specific request. Adjust global count, but
> + * restrict alloc/free to the specified node.
> + */
> + if (nid != NUMA_NO_NODE) {
> + unsigned long old_count = count;
> + count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> + /*
> + * If user specified count causes overflow, set to
> + * largest possible value.
> + */
> + if (count < old_count)
> + count = ULONG_MAX;
> + }
> +
> /*
>* Increase the pool size
>* First take pages out of surplus state. Then make up the
> @@ -2300,7 +2317,6 @@ static int set_max_huge_pages(struct hstate *h, unsigned
> long count,
>* pool might be one hugepage larger than it needs to be, but
>* within all the constraints specified by the sysctls.
>*/
> - spin_lock(_lock);
> while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
> if (!adjust_pool_surplus(h, nodes_allowed, -1))
> break;
> @@ -2421,16 +2437,18 @@ static ssize_t __nr_hugepages_store_common(bool
> obey_mempolicy,
> nodes_allowed = _states[N_MEMORY];
> }
> } else if (nodes_allowed) {
> + /* Node specific request */
> + init_nodemask_of_node(nodes_allowed, nid);
> + } else {
> /*
> - * per node hstate attribute: adjust count to global,
> - * but restrict alloc/free to the specified node.
> + * Node specific request, but we could not allocate
> + * node mask. Pass in ALL nodes, and clear nid.
>*/
> - count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> - init_nodemask_of_node(nodes_allowed, nid);
> - } else
> + nid = NUMA_NO_NODE;
> nodes_allowed = _states[N_MEMORY];
> +
Re: [PATCH v3] x86/boot: Fix incorrect ifdeffery scope
On Mon, Mar 04, 2019 at 01:55:46PM +0800, Baoquan He wrote:
>The declarations related to immovable memory handling are put out of
>the BOOT_COMPRESSED_MISC_H #ifdef scope, wrap them inside.
Looks good, thank you for the fix.
Thanks,
Chao Fan
>
>Signed-off-by: Baoquan He
>---
>v2->v3:
> Add code comment to clearly note the end of the ifdeffery for better
> code reading.
>v1->v2:
> Add the lost line which could be made by git.
> arch/x86/boot/compressed/misc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>index fd13655e0f9b..d2f184165934 100644
>--- a/arch/x86/boot/compressed/misc.h
>+++ b/arch/x86/boot/compressed/misc.h
>@@ -120,8 +120,6 @@ static inline void console_init(void)
>
> void set_sev_encryption_mask(void);
>
>-#endif
>-
> /* acpi.c */
> #ifdef CONFIG_ACPI
> acpi_physical_address get_rsdp_addr(void);
>@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
> #else
> static inline int count_immovable_mem_regions(void) { return 0; }
> #endif
>+
>+#endif /* BOOT_COMPRESSED_MISC_H */
>--
>2.17.2
>
>
>
[PATCH v3] x86/boot: Fix incorrect ifdeffery scope
The declarations related to immovable memory handling are put out of
the BOOT_COMPRESSED_MISC_H #ifdef scope, wrap them inside.
Signed-off-by: Baoquan He
---
v2->v3:
Add code comment to clearly note the end of the ifdeffery for better
code reading.
v1->v2:
Add the lost line which could be made by git.
arch/x86/boot/compressed/misc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd13655e0f9b..d2f184165934 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -120,8 +120,6 @@ static inline void console_init(void)
void set_sev_encryption_mask(void);
-#endif
-
/* acpi.c */
#ifdef CONFIG_ACPI
acpi_physical_address get_rsdp_addr(void);
@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
#else
static inline int count_immovable_mem_regions(void) { return 0; }
#endif
+
+#endif /* BOOT_COMPRESSED_MISC_H */
--
2.17.2
Re: [PATCH v2] x86/boot: Fix incorrect ifdeffery scope
On 03/04/19 at 01:47pm, Chao Fan wrote: > +#endif /* BOOT_COMPRESSED_MISC_H */ > > I am sorry that I should say that in your V1 version, but I really > forgot it after noticing that PATCH log. Yes, that's better. Can note us better where the ifdeffery ends. Will send v3. thx.
Re: [PATCH v2] x86/boot: Fix incorrect ifdeffery scope
On Mon, Mar 04, 2019 at 01:37:56PM +0800, Baoquan He wrote:
>The declarations related to immovable memory handling are put out of
>the BOOT_COMPRESSED_MISC_H #ifdef scope, wrap them inside.
>
>Signed-off-by: Baoquan He
>---
>v1->v2:
> Add the lost line which could be made by git.
>
> arch/x86/boot/compressed/misc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>index fd13655e0f9b..8bbaf362855c 100644
>--- a/arch/x86/boot/compressed/misc.h
>+++ b/arch/x86/boot/compressed/misc.h
>@@ -120,8 +120,6 @@ static inline void console_init(void)
>
> void set_sev_encryption_mask(void);
>
>-#endif
>-
> /* acpi.c */
> #ifdef CONFIG_ACPI
> acpi_physical_address get_rsdp_addr(void);
>@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
> #else
> static inline int count_immovable_mem_regions(void) { return 0; }
> #endif
>+
>+#endif
If it will look better:
+#endif /* BOOT_COMPRESSED_MISC_H */
I am sorry that I should say that in your V1 version, but I really
forgot it after noticing that PATCH log.
Thanks,
Chao Fan
>--
>2.17.2
>
>
>
[PATCH] net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm
For rcu protected pointers, we'd bettter add '__rcu' for them.
No functional change.
Signed-off-by: Su Yanjun
---
include/net/netns/xfrm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
index 59f45b1..d2a36fb 100644
--- a/include/net/netns/xfrm.h
+++ b/include/net/netns/xfrm.h
@@ -57,7 +57,7 @@ struct netns_xfrm {
struct list_headinexact_bins;
- struct sock *nlsk;
+ struct sock __rcu *nlsk;
struct sock *nlsk_stash;
u32 sysctl_aevent_etime;
--
2.7.4
Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
> > > > Let me ask one more question. > > > > > > > > I guess this patch is motivated by > > > > how difficult to convey kernel headers > > > > from vendors to users. > > > > > > > > In that situation, how will the user find > > > > the right compiler to use for building external modules? > > > > > > > > > > > > > > > > > > > > Greg KH said: > > > > > > > > We don't ever support the system of loading a module built with anything > > > > other than the _exact_ same compiler than the kernel was. > > > > > > > > > > > > For the full context, see this: > > > > https://lore.kernel.org/patchwork/patch/836247/#1031547 > > > > > > IMO this issue is not related to this patch but is just an issue with > > > building external modules in general. > > > > > > I do not think it is an issue of the build system, at least. > > > > As far as I understood Greg's comment, it is troublesome > > without the assumption that vmlinux and modules are built > > by the same compiler. > > It is related to this patch since this patch assumes use-cases > > where external modules are built in a completely different environment, > > where a different compiler is probably installed. > > Yes, but what I'm trying to say is the same issue exists with all other > solutions today that do this. Such as debian you have linux-headers package. Distributions provide the compiler in the standard path (/usr/bin/gcc), and users are supposed to use it for building external modules. That's the difference. > A user could totally use the build artifacts obtained from somewhere to build > a kernel module with a completely different compiler. That issue has just to > do with the reality, and isn't an issue caused by any one solution such as > this one. I agree care must be taken whenever user is building external > kernel modules independent of kernel sources. Did I miss something else? > > thanks a lot, > > - Joel > -- Best Regards Masahiro Yamada
Re: [PATCH 05/15] ARM: imx51: fix a leaked reference by addingmissing of_node_put
On Fri, Mar 01, 2019 at 04:56:46PM +0800, Wen Yang wrote: > The call to of_get_next_child returns a node pointer with refcount > incremented thus it must be explicitly decremented after the last > usage. > > Detected by coccinelle with the following warnings: > ./arch/arm/mach-imx/mach-imx51.c:64:2-8: ERROR: missing of_node_put; acquired > a node pointer with refcount incremented on line 57, but without a > corresponding object release within this function. > > Signed-off-by: Wen Yang Applied, thanks.
[PATCH v2] x86/boot: Fix incorrect ifdeffery scope
The declarations related to immovable memory handling are put out of
the BOOT_COMPRESSED_MISC_H #ifdef scope, wrap them inside.
Signed-off-by: Baoquan He
---
v1->v2:
Add the lost line which could be made by git.
arch/x86/boot/compressed/misc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd13655e0f9b..8bbaf362855c 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -120,8 +120,6 @@ static inline void console_init(void)
void set_sev_encryption_mask(void);
-#endif
-
/* acpi.c */
#ifdef CONFIG_ACPI
acpi_physical_address get_rsdp_addr(void);
@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
#else
static inline int count_immovable_mem_regions(void) { return 0; }
#endif
+
+#endif
--
2.17.2
Re: [PATCH v3] arm64: dts: ls1028a: Add Audio DT nodes
On Fri, Mar 01, 2019 at 03:46:32PM +0800, Alison Wang wrote: > This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards. > > Signed-off-by: Alison Wang Applied, thanks.
Re: [PATCH] x86/boot: Fix incorrect ifdeffery scope
On 03/04/19 at 01:32pm, Chao Fan wrote: > On Mon, Mar 04, 2019 at 12:18:20PM +0800, Baoquan He wrote: > >The declarations related to immovable memory handling are put out of > > > >Signed-off-by: Baoquan He > > Are there some problems in your mail tool? > I can only see one line in the PATCH log and seems a half sentence. Yeah, just notice it. I will send a new one. Sorry.
Re: [PATCH v2] ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port
On Fri, Mar 01, 2019 at 08:26:42AM +0100, Michal Vokáč wrote:
> Use rgmii-id phy mode for the CPU port (MAC0) of the QCA8334 switch
> to add delays to both Tx and Rx clock.
>
> It worked with the rgmii mode before because the qca8k driver
> (incorrectly) enabled delays in that mode and rgmii-id was not
> implemented at all.
>
> Commit 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode")
> removed the delays from the RGMII mode and hence broke the networking.
>
> To fix the problem, commit a968b5e9d587 ("net: dsa: qca8k: Enable delay
> for RGMII_ID mode") was introduced.
>
> Now the correct phy mode is available so use it.
>
> Signed-off-by: Michal Vokáč
Applied, thanks.
Re: [PATCH] x86/boot: Fix incorrect ifdeffery scope
On Mon, Mar 04, 2019 at 12:18:20PM +0800, Baoquan He wrote:
>The declarations related to immovable memory handling are put out of
>
>Signed-off-by: Baoquan He
Are there some problems in your mail tool?
I can only see one line in the PATCH log and seems a half sentence.
Thanks,
Chao Fan
>---
> arch/x86/boot/compressed/misc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>index fd13655e0f9b..8bbaf362855c 100644
>--- a/arch/x86/boot/compressed/misc.h
>+++ b/arch/x86/boot/compressed/misc.h
>@@ -120,8 +120,6 @@ static inline void console_init(void)
>
> void set_sev_encryption_mask(void);
>
>-#endif
>-
> /* acpi.c */
> #ifdef CONFIG_ACPI
> acpi_physical_address get_rsdp_addr(void);
>@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
> #else
> static inline int count_immovable_mem_regions(void) { return 0; }
> #endif
>+
>+#endif
>--
>2.17.2
>
>
>
Re: [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest
On Fri, Mar 01, 2019 at 06:58:19AM -0800, Sean Christopherson wrote:
> On Thu, Feb 28, 2019 at 04:38:44PM +0800, Yang Weijiang wrote:
> > On Thu, Feb 28, 2019 at 08:17:15AM -0800, Sean Christopherson wrote:
> > > On Mon, Feb 25, 2019 at 09:27:14PM +0800, Yang Weijiang wrote:
> > > > "Load Guest CET state" bit controls whether guest CET states
> > > > will be loaded at Guest entry. Before doing that, KVM needs
> > > > to check if CPU CET feature is available.
> > > >
> > > > Signed-off-by: Zhang Yi Z
> > > > Signed-off-by: Yang Weijiang
> > > > ---
> > > > arch/x86/kvm/vmx.c | 32
> > > > 1 file changed, 32 insertions(+)
> > > >
> > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > > index 89ee086e1729..d32cee9ee079 100644
> > > > --- a/arch/x86/kvm/vmx.c
> > > > +++ b/arch/x86/kvm/vmx.c
> > > > @@ -55,6 +55,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include "trace.h"
> > > > #include "pmu.h"
> > > > @@ -4065,6 +4066,20 @@ static inline bool
> > > > vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu,
> > > > return !(val & ~valid_bits);
> > > > }
> > > >
> > > > +static int vmx_guest_cet_cap(struct kvm_vcpu *vcpu)
> > > > +{
> > > > + u32 eax, ebx, ecx, edx;
> > > > +
> > > > + /*
> > > > +* Guest CET can work as long as HW supports the feature,
> > > > independent
> > > > +* to Host SW enabling status.
> > > > +*/
> > > > + cpuid_count(7, 0, , , , );
> > > > +
> > > > + return ((ecx & bit(X86_FEATURE_SHSTK)) |
> > > > + (edx & bit(X86_FEATURE_IBT))) ? 1 : 0;
> > >
> > > Given the holes in the (current) architecture/spec, I think KVM has to
> > > require both features to be supported in the guest to allow CR4.CET to
> > > be enabled.
> > The reason why I use a "OR" here is to keep CET enabling control the
> > same as that on host, right now on host, users can select to enable SHSTK
> > or IBT
> > feature by disabling the unexpected one. It's free to select SHSTK & IBT
> > or SHSTK | IBT.
>
> Which is not the same as SHSTK != IBT in *hardware*, which is effectively
> what this is allowing for the guest. The problem is that the architecture
> doesn't cleanly separate the two features, i.e. we'd have a virtualization
> hole where the guest could touch state for a disabled feature.
>
> Regardless, the guest would still be able to selectively enable each CET
> feature, it would just never see a model where SHSTK != IBT.
Hi, Sean,
I'd like to understand your concerns. From my point of view, e.g.,
when only IBT is enabled, PL3_SSP MSR would be unnecessrily exposed,
this is the design "limitation", but PL3_SSP keeps 0 if SHSTK is not
configured. Could you detail your concerns?
Re: [RFC PATCH v1 00/25] printk: new implementation
On (02/13/19 15:15), John Ogness wrote: > I don't like bust_spinlocks() because drivers end up implementing > oops_in_progress with exactly that... ignoring their own locks. I prefer > consoles are provided with a locking mechanism that they can use to > support a separate NMI-safe write function. My series introduces > console_atomic_lock() for exactly this purpose. > > But this doesn't help here. Here we are talking about a crashing system > that does _not_ have an emergency console. And in this case I would say > messages would be lost (just like they are now if all you have is a vt > console and it was busy). > > I suppose we could keep the current bust_spinlocks() stuff for the > special case that there are no emergency consoles available. It's better > than nothing, but also not really reliable. Preferrably we figure out > how to implement write_atomic for all console drivers. Right. We set console loglevel to verbose before the final panic flush, so flush of all unseen messages (regardless of importance) does look quite reasonable (and this is what panic() has been doing for many years). -ss
Re: [PATCH v9 02/11] powerpc: prepare string/mem functions for KASAN
Hi Christophe, > diff --git a/arch/powerpc/include/asm/kasan.h > b/arch/powerpc/include/asm/kasan.h > new file mode 100644 > index ..c3161b8fc017 > --- /dev/null > +++ b/arch/powerpc/include/asm/kasan.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __ASM_KASAN_H > +#define __ASM_KASAN_H > + > +#ifdef CONFIG_KASAN > +#define _GLOBAL_KASAN(fn).weak fn ; _GLOBAL(__##fn) ; _GLOBAL(fn) > +#define _GLOBAL_TOC_KASAN(fn).weak fn ; _GLOBAL_TOC(__##fn) ; > _GLOBAL_TOC(fn) > +#define EXPORT_SYMBOL_KASAN(fn) EXPORT_SYMBOL(__##fn) ; > EXPORT_SYMBOL(fn) I'm having some trouble with this. I get warnings like this: WARNING: EXPORT symbol "__memcpy" [vmlinux] version generation failed, symbol will not be versioned. It seems to be related to the export line, as if I swap the exports to do fn before __##fn I get: WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned. I have narrowed this down to combining 2 EXPORT_SYMBOL()s on one line. This works - no warning: EXPORT_SYMBOL(memset) EXPORT_SYMBOL(__memset) This throws a warning: EXPORT_SYMBOL(memset) ; EXPORT_SYMBOL(__memset) I notice in looking at the diff of preprocessed source we end up invoking an asm macro that doesn't seem to have a full final argument, I wonder if that's relevant... -___EXPORT_SYMBOL __memset, __memset, ; ___EXPORT_SYMBOL memset, memset, +___EXPORT_SYMBOL __memset, __memset, +___EXPORT_SYMBOL memset, memset, I also notice that nowhere else in the source do people have multiple EXPORT_SYMBOLs on the same line, and other arches seem to just unconditionally export both symbols on multiple lines. I have no idea how this works for you - maybe it's affected by something 32bit. How would you feel about this approach instead? I'm not tied to any of the names or anything. diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index e0637730a8e7..7b6a91b448dd 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -214,6 +214,9 @@ name: \ #define DOTSYM(a) a +#define PROVIDE_WEAK_ALIAS(strongname, weakname) \ + .weak weakname ; .set weakname, strongname ; + #else #define XGLUE(a,b) a##b @@ -236,6 +239,10 @@ GLUE(.,name): #define DOTSYM(a) GLUE(.,a) +#define PROVIDE_WEAK_ALIAS(strongname, weakname) \ + .weak weakname ; .set weakname, strongname ; \ + .weak DOTSYM(weakname) ; .set DOTSYM(weakname), DOTSYM(strongname) ; + #endif #else /* 32-bit */ @@ -251,6 +258,9 @@ GLUE(.,name): #define _GLOBAL_TOC(name) _GLOBAL(name) +#define PROVIDE_WEAK_ALIAS(strongname, weakname) \ + .weak weakname ; .set weakname, strongname ; + #endif /* --- a/arch/powerpc/lib/mem_64.S +++ b/arch/powerpc/lib/mem_64.S @@ -33,7 +33,8 @@ EXPORT_SYMBOL(__memset32) EXPORT_SYMBOL(__memset64) #endif -_GLOBAL_KASAN(memset) +PROVIDE_WEAK_ALIAS(__memset,memset) +_GLOBAL(__memset) neg r0,r3 rlwimi r4,r4,8,16,23 andi. r0,r0,7 /* # bytes to be 8-byte aligned */ @@ -98,9 +99,11 @@ _GLOBAL_KASAN(memset) 10:bflr31 stb r4,0(r6) blr -EXPORT_SYMBOL_KASAN(memset) +EXPORT_SYMBOL(memset) +EXPORT_SYMBOL(__memset) -_GLOBAL_TOC_KASAN(memmove) +PROVIDE_WEAK_ALIAS(__memmove,memove) +_GLOBAL_TOC(__memmove) cmplw 0,r3,r4 bgt backwards_memcpy b memcpy @@ -141,4 +144,5 @@ _GLOBAL(backwards_memcpy) beq 2b mtctr r7 b 1b -EXPORT_SYMBOL_KASAN(memmove) +EXPORT_SYMBOL(memmove) +EXPORT_SYMBOL(__memmove) diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S index 862b515b8868..7c1b09556cad 100644 --- a/arch/powerpc/lib/memcpy_64.S +++ b/arch/powerpc/lib/memcpy_64.S @@ -19,7 +19,8 @@ #endif .align 7 -_GLOBAL_TOC_KASAN(memcpy) +PROVIDE_WEAK_ALIAS(__memcpy,memcpy) +_GLOBAL_TOC(__memcpy) BEGIN_FTR_SECTION #ifdef __LITTLE_ENDIAN__ cmpdi cr7,r5,0 @@ -230,4 +231,5 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) 4: ld r3,-STACKFRAMESIZE+STK_REG(R31)(r1) /* return dest pointer */ blr #endif -EXPORT_SYMBOL_KASAN(memcpy) +EXPORT_SYMBOL(__memcpy) +EXPORT_SYMBOL(memcpy) Regards, Daniel > +#else > +#define _GLOBAL_KASAN(fn)_GLOBAL(fn) > +#define _GLOBAL_TOC_KASAN(fn)_GLOBAL_TOC(fn) > +#define EXPORT_SYMBOL_KASAN(fn) EXPORT_SYMBOL(fn) > +#endif > + > +#endif > diff --git a/arch/powerpc/include/asm/string.h > b/arch/powerpc/include/asm/string.h > index 1647de15a31e..9bf6dffb4090 100644 > --- a/arch/powerpc/include/asm/string.h > +++ b/arch/powerpc/include/asm/string.h > @@ -4,14 +4,17 @@ > > #ifdef __KERNEL__ > > +#ifndef CONFIG_KASAN > #define __HAVE_ARCH_STRNCPY > #define __HAVE_ARCH_STRNCMP > +#define __HAVE_ARCH_MEMCHR > +#define __HAVE_ARCH_MEMCMP > +#define __HAVE_ARCH_MEMSET16 > +#endif > + > #define __HAVE_ARCH_MEMSET > #define
Re: [PATCH v3 0/3] arm: dts: imx8mq: Add cpufreq support
On Thu, Feb 28, 2019 at 09:42:43PM +, Abel Vesa wrote: > Changes since v2: > * renamed the regulator > * removed the useless enable-active-high from the regulator > * renamed a53_0_opp_table to a53_opp_table > > Abel Vesa (3): > arm64: dts: imx8mq: Add the clocks and the latencies for the A53 cores > arm64: dts: imx8mq: Add the buck vdd_arm regulator > arm64: dts: imx8mq: Add the opp table and cores opp properties Applied all, thanks.
Re: [RFC PATCH v1 00/25] printk: new implementation
On (02/13/19 15:43), John Ogness wrote: > On 2019-02-13, Sergey Senozhatsky wrote: > >> - A dedicated kernel thread is created for printing to all consoles in > >> a fully preemptible context. > > > > How do you handle sysrq- printouts on systems which can't > > schedule printk-kthread? > > If those sysrq printouts are at the emergency loglevel (which most are), > then they are printed immediately to the emergency consoles. This has > already proved useful for our own kernel debugging work. For example, > currently sysrq-z for very large traces result in messages being dropped > because of printk buffer overflows. But with the emergency console we > always see the full trace buffer. Are we sure that all systems will always have ->atomic console(-s) enabled? Is it possible to convert all console drivers to ->atomic? fbcon, for instance (with scrolling and font scaling, etc)? If there are setups which can be fully !atomic (in terms of console output) then we, essentially, have a fully preemptible kthread printk implementation. > Because you have already done so much work and experimentation with > printk-kthreads, I feel like many of your comments are related to your > kthread work in this area. Really the big design change I make with my > printk-kthread is that it is only for non-critical messages. For > anything critical, users should rely on an emergency console. Fair point. Well maybe my printk-kthread comments are not utterly unreasonable, but who knows :) -ss
Re: [PATCH v4 00/10] Add basic support for Socionext Milbeaut M10V SoC
Hi, On 2019/03/01 23:34, Arnd Bergmann wrote: On Wed, Feb 27, 2019 at 5:51 AM Sugaya Taichi wrote: Hi, Here is the series of patches the initial support for SC2000(M10V) of Milbeaut SoCs. "M10V" is the internal name of SC2000, so commonly used in source code. SC2000 is a SoC of the Milbeaut series. equipped with a DSP optimized for computer vision. It also features advanced functionalities such as 360-degree, real-time spherical stitching with multi cameras, image stabilization for without mechanical gimbals, and rolling shutter correction. More detail is below: https://www.socionext.com/en/products/assp/milbeaut/SC2000.html Specifications for developers are below: - Quad-core 32bit Cortex-A7 on ARMv7-A architecture - NEON support - DSP - GPU - MAX 3GB DDR3 - Cortex-M0 for power control - NAND Flash Interface - SD UHS-I - SD UHS-II - SDIO - USB2.0 HOST / Device - USB3.0 HOST / Device - PCI express Gen2 - Ethernet Engine - I2C - UART - SPI - PWM Support is quite minimal for now, since it only includes timer, clock, pictrl and serial controller drivers, so we can only boot to userspace through initramfs. Support for the other peripherals will come eventually. I've merged these all into the arm/newsoc branch now, with the exception of the patch that Greg has already taken. I'll do a little more build testing before that branch will be sent, but I expect it will be fine. Arnd Thanks a lot!
Re: [PATCH net] net: hns3: add rmb() for rx description
From: Huazhong Tan
Date: Sat, 2 Mar 2019 16:49:30 +0800
> From: Jian Shen
>
> HW can not guarantee complete write desc->rx.size, even though
> HNS3_RXD_VLD_B has been set. Driver needs to add rmb() instruction
> to make sure desc->rx.size is always valid.
>
> Fixes: e55970950556 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in
> NAPI poll")
> Signed-off-by: Jian Shen
> Signed-off-by: Huazhong Tan
dma_rmb() is more appropriate here and more efficient.
Re: [PATCH] net-sysfs: Fix mem leak in netdev_register_kobject
From: Yue Haibing Date: Sat, 2 Mar 2019 10:34:55 +0800 > From: YueHaibing > > syzkaller report this: > BUG: memory leak > unreferenced object 0x88837a71a500 (size 256): > comm "syz-executor.2", pid 9770, jiffies 4297825125 (age 17.843s) > hex dump (first 32 bytes): > 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. > ff ff ff ff ff ff ff ff 20 c0 ef 86 ff ff ff ff ... > backtrace: > [] netdev_register_kobject+0x124/0x2e0 > net/core/net-sysfs.c:1751 > [ ] register_netdevice+0xcc1/0x1270 net/core/dev.c:8516 > [ ] tun_set_iff drivers/net/tun.c:2649 [inline] > [ ] __tun_chr_ioctl+0x2218/0x3d20 drivers/net/tun.c:2883 > [<1b8ac127>] vfs_ioctl fs/ioctl.c:46 [inline] > [<1b8ac127>] do_vfs_ioctl+0x1a5/0x10e0 fs/ioctl.c:690 > [<79b269f8>] ksys_ioctl+0x89/0xa0 fs/ioctl.c:705 > [ ] __do_sys_ioctl fs/ioctl.c:712 [inline] > [ ] __se_sys_ioctl fs/ioctl.c:710 [inline] > [ ] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:710 > [<7ebded1e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290 > [ ] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [<115be9bb>] 0x > > It should call kset_unregister to free 'dev->queues_kset' > in error path of register_queue_kobjects, otherwise will cause a mem leak. > > Reported-by: Hulk Robot > Fixes: 1d24eb4815d1 ("xps: Transmit Packet Steering") > Signed-off-by: YueHaibing Wow, what an ancient bug. Applied and queued up for -stable, thanks.
Re: [PATCH] fsl/fman: Use vsprintf extension %pM
From: Joe Perches Date: Fri, 01 Mar 2019 16:37:25 -0800 > Make logging of an ethernet address more consistent with > the rest of the kernel. > > Miscellanea: > > The %02hx use also did not quite match the u8 definition > of addr though that did not actually matter given normal > integer promotion rules. > > Signed-off-by: Joe Perches Applied to net-next, thanks Joe.
Re: [PATCH] net: ipv6: add socket option IPV6_ROUTER_ALERT_ISOLATE
From: frugg...@arista.com (Francesco Ruggeri) Date: Fri, 01 Mar 2019 15:31:03 -0800 > By default IPv6 socket with IPV6_ROUTER_ALERT socket option set will > receive all IPv6 RA packets from all namespaces. > IPV6_ROUTER_ALERT_ISOLATE socket option restricts packets received by > the socket to be only from the socket's namespace. > > Signed-off-by: Maxim Martynov > Signed-off-by: Francesco Ruggeri Applied to net-next, thanks.
[PATCH v3 1/3] perf diff: Support --time filter option
For better support for perf diff, it would be useful to add --time filter
option to diff the samples within given time window.
It supports time percent with multipe time ranges. Time string is
'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'.
For example:
Select the second 10% time slice to diff:
perf diff --time 10%/2
Select from 0% to 10% time slice to diff:
perf diff --time 0%-10%
Select the first and the second 10% time slices to diff:
perf diff --time 10%/1,10%/2
Select from 0% to 10% and 30% to 40% slices to diff:
perf diff --time 0%-10%,30%-40%
It also supports to analyze samples within given time window as:
,. Times have the format seconds.microseconds. If start
is not given (i.e., time string is ',x.y') then analysis starts at
the beginning of the file. If stop time is not given (i.e, time
string is 'x.y,') then analysis goes to end of file. Time string is
'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different
perf.data files.
For example, we get the timestamp information from perf script.
perf script -i perf.data.old
mgen 13940 [000] 3946.361400: ...
perf script -i perf.data
mgen 13940 [000] 3971.150589 ...
perf diff --time 3946.361400,:3971.150589,
It analyzes the perf.data.old from the timestamp 3946.361400 to
the end of perf.data.old and analyzes the perf.data from the
timestamp 3971.150589 to the end of perf.data.
v3:
---
Don't parse the time string if --time option is not set.
Refactor the code to make it simpler.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 41 ++
tools/perf/builtin-diff.c | 136 +
2 files changed, 164 insertions(+), 13 deletions(-)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index a79c84a..5bfe876 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -118,6 +118,47 @@ OPTIONS
sum of shown entries will be always 100%. "absolute" means it retains
the original value before and after the filter is applied.
+--time::
+ Analyze samples within given time window. It supports time
+ percent with multipe time ranges. Time string is 'a%/n,b%/m,...'
+ or 'a%-b%,c%-%d,...'.
+
+ For example:
+
+ Select the second 10% time slice to diff:
+ perf diff --time 10%/2
+
+ Select from 0% to 10% time slice to diff:
+ perf diff --time 0%-10%
+
+ Select the first and the second 10% time slices to diff:
+ perf diff --time 10%/1,10%/2
+
+ Select from 0% to 10% and 30% to 40% slices to diff:
+ perf diff --time 0%-10%,30%-40%
+
+ It also supports to analyze samples within given time window:
+ ,. Times have the format seconds.microseconds. If start
+ is not given (i.e., time string is ',x.y') then analysis starts at
+ the beginning of the file. If stop time is not given (i.e, time
+ string is 'x.y,') then analysis goes to end of file. Time string is
+ 'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different
+ perf.data files.
+
+ For example, we get the timestamp information from perf script.
+
+ perf script -i perf.data.old
+ mgen 13940 [000] 3946.361400: ...
+
+ perf script -i perf.data
+ mgen 13940 [000] 3971.150589 ...
+
+ perf diff --time 3946.361400,:3971.150589,
+
+ It analyzes the perf.data.old from the timestamp 3946.361400 to
+ the end of perf.data.old and analyzes the perf.data from the
+ timestamp 3971.150589 to the end of perf.data.
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 58fe0e8..2c49dda 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -19,12 +19,21 @@
#include "util/util.h"
#include "util/data.h"
#include "util/config.h"
+#include "util/time-utils.h"
#include
#include
#include
#include
+struct perf_diff {
+ struct perf_tool tool;
+ const char *time_str;
+ struct perf_time_interval *ptime_range;
+ int range_size;
+ int range_num;
+};
+
/* Diff command specific HPP columns. */
enum {
PERF_HPP_DIFF__BASELINE,
@@ -323,16 +332,22 @@ static int formula_fprintf(struct hist_entry *he, struct
hist_entry *pair,
return -1;
}
-static int diff__process_sample_event(struct perf_tool *tool __maybe_unused,
+static int diff__process_sample_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
struct perf_evsel *evsel,
struct machine *machine)
{
+ struct perf_diff *pdiff = container_of(tool,
[PATCH v3 2/3] perf diff: Support --cpu filter option
For better support for perf diff, it would be useful to add --cpu filter
option.
Multiple CPUs can be provided as a comma-separated list with no space: 0,1.
Ranges of CPUs are specified with -: 0-2. Default is to report samples on
all CPUs.
For example,
perf diff --cpu 0,1
It only diff the samples for CPU0 and CPU1.
v3:
---
No logical changes
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 5 +
tools/perf/builtin-diff.c | 16
2 files changed, 21 insertions(+)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index 5bfe876..ed13b3f 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -159,6 +159,11 @@ OPTIONS
the end of perf.data.old and analyzes the perf.data from the
timestamp 3971.150589 to the end of perf.data.
+--cpu:: Only diff samples for the list of CPUs provided. Multiple CPUs can
+ be provided as a comma-separated list with no space: 0,1. Ranges of
+ CPUs are specified with -: 0-2. Default is to report samples on all
+ CPUs.
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 2c49dda..cebf394 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -83,6 +83,9 @@ static unsigned int sort_compute = 1;
static s64 compute_wdiff_w1;
static s64 compute_wdiff_w2;
+static const char *cpu_list;
+static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+
enum {
COMPUTE_DELTA,
COMPUTE_RATIO,
@@ -354,6 +357,11 @@ static int diff__process_sample_event(struct perf_tool
*tool,
return -1;
}
+ if (cpu_list && !test_bit(sample->cpu, cpu_bitmap)) {
+ ret = 0;
+ goto out_put;
+ }
+
if (!hists__add_entry(hists, , NULL, NULL, NULL, sample, true)) {
pr_warning("problem incrementing symbol period, skipping
event\n");
goto out_put;
@@ -882,6 +890,13 @@ static int __cmd_diff(void)
goto out_delete;
}
+ if (cpu_list) {
+ ret = perf_session__cpu_bitmap(d->session, cpu_list,
+ cpu_bitmap);
+ if (ret < 0)
+ goto out_delete;
+ }
+
ret = perf_session__process_events(d->session);
if (ret) {
pr_err("Failed to process %s\n", d->data.path);
@@ -959,6 +974,7 @@ static const struct option options[] = {
"How to display percentage of filtered entries",
parse_filter_percentage),
OPT_STRING(0, "time", _str, "str",
"Time span (time percent or absolute timestamp)"),
+ OPT_STRING(0, "cpu", _list, "cpu", "list of cpus to profile"),
OPT_END()
};
--
2.7.4
[PATCH v3 3/3] perf diff: Support --pid/--tid filter options
For better filtering support for perf diff, it would be useful to
add --pid and --tid filter options.
For example,
perf diff --tid 13965
It only diff the samples for thread 13965.
v3:
---
No logical changes.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 6 ++
tools/perf/builtin-diff.c | 4
2 files changed, 10 insertions(+)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index ed13b3f..83c9496 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -164,6 +164,12 @@ OPTIONS
CPUs are specified with -: 0-2. Default is to report samples on all
CPUs.
+--pid=::
+ Only diff samples for given process ID (comma separated list).
+
+--tid=::
+ Only diff samples for given thread ID (comma separated list).
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index cebf394..222abeb 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -975,6 +975,10 @@ static const struct option options[] = {
OPT_STRING(0, "time", _str, "str",
"Time span (time percent or absolute timestamp)"),
OPT_STRING(0, "cpu", _list, "cpu", "list of cpus to profile"),
+ OPT_STRING(0, "pid", _conf.pid_list_str, "pid[,pid...]",
+ "only consider symbols in these pids"),
+ OPT_STRING(0, "tid", _conf.tid_list_str, "tid[,tid...]",
+ "only consider symbols in these tids"),
OPT_END()
};
--
2.7.4
[PATCH v3 0/3] perf diff: Add new filter options
This patch series creates following new filter options for perf diff. --time: It supports time percent with multipe time ranges. Time string is 'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'. For example: Select the second 10% time slice to diff: perf diff --time 10%/2 Select from 0% to 10% time slice to diff: perf diff --time 0%-10% Select the first and the second 10% time slices to diff: perf diff --time 10%/1,10%/2 Select from 0% to 10% and 30% to 40% slices to diff: perf diff --time 0%-10%,30%-40% It also supports to analyze samples within given time window as: ,. Times have the format seconds.microseconds. If start is not given (i.e., time string is ',x.y') then analysis starts at the beginning of the file. If stop time is not given (i.e, time string is 'x.y,') then analysis goes to end of file. Time string is 'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different perf.data files. For example, we get the timestamp information from perf script. perf script -i perf.data.old mgen 13940 [000] 3946.361400: ... perf script -i perf.data mgen 13940 [000] 3971.150589 ... perf diff --time 3946.361400,:3971.150589, It analyzes the perf.data.old from the timestamp 3946.361400 to the end of perf.data.old and analyzes the perf.data from the timestamp 3971.150589 to the end of perf.data. --cpu: Only diff samples for the list of CPUs provided. Multiple CPUs can be provided as a comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2. Default is to report samples on all CPUs. For example: perf diff --cpu 0,1 It only diff the samples for CPU0 and CPU1. --pid: Only diff samples for given process ID (comma separated list). --tid: Only diff samples for given thread ID (comma separated list). For example, perf diff --tid 13965 It only diff the samples for thread 13965. v3: --- Update patch "perf diff: Support --time filter option" according to Jiri's comments. Others are no logical changes. Jin Yao (3): perf diff: Support --time filter option perf diff: Support --cpu filter option perf diff: Support --pid/--tid filter options tools/perf/Documentation/perf-diff.txt | 52 +++ tools/perf/builtin-diff.c | 156 ++--- 2 files changed, 195 insertions(+), 13 deletions(-) -- 2.7.4
Re: [PATCH] net: fixup address-space warnings in compat_mc_{get,set}sockopt()
From: Ben Dooks Date: Fri, 1 Mar 2019 18:39:44 + > Add __user attributes in some of the casts in this function to avoid > the following sparse warnings: > > net/compat.c:592:57: warning: cast removes address space of expression > net/compat.c:592:57: warning: incorrect type in initializer (different > address spaces) > net/compat.c:592:57:expected struct compat_group_req [noderef] > *gr32 > net/compat.c:592:57:got void * > net/compat.c:613:65: warning: cast removes address space of expression > net/compat.c:613:65: warning: incorrect type in initializer (different > address spaces) > net/compat.c:613:65:expected struct compat_group_source_req [noderef] > *gsr32 > net/compat.c:613:65:got void * > net/compat.c:634:60: warning: cast removes address space of expression > net/compat.c:634:60: warning: incorrect type in initializer (different > address spaces) > net/compat.c:634:60:expected struct compat_group_filter [noderef] > *gf32 > net/compat.c:634:60:got void * > net/compat.c:672:52: warning: cast removes address space of expression > net/compat.c:672:52: warning: incorrect type in initializer (different > address spaces) > net/compat.c:672:52:expected struct compat_group_filter [noderef] > *gf32 > net/compat.c:672:52:got void * > > Signed-off-by: Ben Dooks Applied to net-next, thanks.
Re: [RFC PATCH nand-next 0/2] meson-nand: support for older SoCs
Hello Martin, On 2019/3/2 2:29, Martin Blumenstingl wrote: Hi Liang, I am trying to add support for older SoCs to the meson-nand driver. Back when the driver was in development I used an early revision (of your driver) and did some modifications to make it work on older SoCs. Now that the driver is upstream I wanted to give it another try and make a real patch out of it. Unfortunately it's not working anymore. As far as I know the NFC IP block revision on GXL is similar (or even the same?) as on all older SoCs. As far as I can tell only the clock setup is different on the older SoCs (which have a dedicated NAND clock): - we don't need the "amlogic,mmc-syscon" property on the older SoCs because we don't need to setup any muxing (common clock framework will do everything for us) - "rx" and "tx" clocks don't exist - I could not find any other differences between Meson8, Meson8b, Meson8m2, GXBB and GXL That is right. the serials NFC is almost the same except: 1) The clock control and source that M8-serials are not share with EMMC. 2) The base register address 3) DMA encryption option which we don't care on NFC driver. In this series I'm sending two patches which add support for the older SoCs. Unfortunately these patches are currently not working for me (hence the "RFC" prefix). I get a (strange) crash which is triggered by the kzalloc() in meson_nfc_read_buf() - see below for more details. Can you please help me on this one? I'd like to know whether: - the meson-nand driver works for you on GXL or AXG on linux-next? (I was running these patches on top of next-20190301 on my M8S board which uses a 32-bit Meson8m2 SoC. I don't have any board using a GXL SoC which also has NAND) Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but i an not sure it runs the same flow with yours. because i see the print "Counld not find a valid ONFI parameter page, " in yours. i will try to reproduce it on AXG(i don't have a M8 platform now). - you see any issue with my patches? (maybe I missed more differences between GXL and the older SoCs) i think it is ok now. kernel log extract: [...] Could not find a valid ONFI parameter page, trying bit-wise majority to recover it ONFI parameter recovery failed, aborting Unable to handle kernel paging request at virtual address 8011 pgd = (ptrval) [8011] *pgd= Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc8-next-20190301-00053-g50ac6f7757e2 #4145 Hardware name: Amlogic Meson platform PC is at kmem_cache_alloc_trace+0xc8/0x268 LR is at kmem_cache_alloc_trace+0x2c/0x268 pc : []lr : []psr: 6013 sp : c02adc58 ip : e9e7a440 fp : 4ee2 r10: 8011 r9 : e000 r8 : c110918c r7 : 0008 r6 : c08967c0 r5 : 0dc0 r4 : c0201e40 r3 : c109dd30 r2 : r1 : 4ee2 r0 : Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 0020404a DAC: 0051 Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) Stack: (0xc02adc58 to 0xc02ae000) dc40: e9d84048 0003 dc60: e9e7a440 c02add18 0028 e9e68680 c02adcf0 0003 e9d84048 0002 dc80: e9e7a440 c08967c0 c1108cb4 c02adcdc 10624dd3 c02adce4 10624dd3 0005 dca0: e9e7a440 c0f5c310 0028 c0f09998 0005 e9d84048 0005 c02add57 dcc0: c1108c88 e9e7a440 c02adcf0 e9d84428 e9d843b0 c0882258 00ff 4000 dce0: c02adce8 c02adcf0 0003 0090 dd00: 0001 0001 c02adcdf 0190 0002 0005 dd20: c02add57 0001 a10a1ef7 c1108c88 c1180250 e9d843c0 dd40: 0001 00de c088d114 c0f08db4 00d843c0 a10a1ef7 dd60: 0015 e9d84048 c1108c88 c088d470 e9d84048 c0b4 6013 dd80: c0eebc9c 00ad c0da01ac e9e7a48c c0cc6d50 c12122cc a10a1ef7 dda0: e9e7a440 e9e7a440 e9d84040 c0eebc9c e987f410 eafd6748 e9d84048 c1108c88 ddc0: e9e7a48c c0895c70 e9871f00 e9e7a440 c04eef60 eafd64bc dde0: e9e7a534 0001 a10a1ef7 e987f410 de00: c1180728 c1180728 c1071854 c07fd388 de20: c120da38 e987f410 c120da3c c07fb410 e987f410 c1180728 de40: c1180728 c07fb910 c1071834 c10004a8 c07fb65c c10004a8 c0a917b4 de60: c0da1914 e987f410 c1180728 c07fb910 c1071834 c10004a8 de80: c1071854 c07fb908 c1180728 e987f410 c07fb968 e98b8eb4 c1108c88 dea0: c1180728 c07f97d4 c1175260 c029a958 e98b8eb4 a10a1ef7 c029a96c c1180728 dec0: e9e1fa80 c1175260 c07fa844 c0f09c64 c1108c88 e000 c1180728 dee0: c1108c88 e000 c103b788 c07fc494 c11c2ca0 c1108c88 e000 c0302f1c df00: ebfffd96 c0346f90 c0fab8a0 c0f2ad00 0006 0006 c0e9e26c df20: c1108c88 c0eb11b0 c0e9e2e0 c11d1300 ebfffd84 ebfffd89 a10a1ef7
Re: [PATCH net-next v2] net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()
From: Florian Fainelli
Date: Fri, 1 Mar 2019 10:37:25 -0800
> We were skipping the prepare phase which causes some problems with at
> least a couple of drivers:
>
> - mv88e6xxx chooses to skip programming VID = 0 with -EOPNOTSUPP in
> the prepare phase, but we would still try to force this VID since we
> would only call the commit phase and so we would get the driver to
> return -EINVAL instead
>
> - qca8k does not currently have a port_vlan_add() callback implemented,
> yet we would try to call that unconditionally leading to a NPD
>
> Fix both issues by conforming to the current model doing a
> prepare/commit phase, this makes us consistent throughout the code and
> assumptions.
>
> Reported-by: Heiner Kallweit
> Reported-by: Michal Vokáč
> Fixes: 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid
> implementation")
> Signed-off-by: Florian Fainelli
Applied, thanks Florian.
[PATCH] regulator: tps65217: Simplify linear range for selector 25-52
The original code separates the selector 25-52 into 2 ranges on purpose
because DCDC1/DCDC3 only support up to 1.8V/1.5V in the old code.
Both DCDC1 and DCDC3 support up to 3.3V since commit b4c2e158a1e1
("regulator: tps65217: Allow DCDC1 and DCDC3 up to 3.3V"), so merge
25-30 and 31-52 ranges to one range.
Signed-off-by: Axel Lin
---
drivers/regulator/tps65217-regulator.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
index d84fab616abf..ada62f792258 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -58,8 +58,7 @@ static const unsigned int LDO1_VSEL_table[] = {
static const struct regulator_linear_range tps65217_uv1_ranges[] = {
REGULATOR_LINEAR_RANGE(90, 0, 24, 25000),
- REGULATOR_LINEAR_RANGE(155, 25, 30, 5),
- REGULATOR_LINEAR_RANGE(185, 31, 52, 5),
+ REGULATOR_LINEAR_RANGE(155, 25, 52, 5),
REGULATOR_LINEAR_RANGE(300, 53, 55, 10),
REGULATOR_LINEAR_RANGE(330, 56, 62, 0),
};
--
2.17.1
RE: [RFC net-next 0/8] Introducing subdev bus and devlink extension
> -Original Message- > From: Jakub Kicinski > Sent: Friday, March 1, 2019 2:04 PM > To: Parav Pandit ; Or Gerlitz > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; > michal.l...@markovi.net; da...@davemloft.net; > gre...@linuxfoundation.org; Jiri Pirko > Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension > > On Thu, 28 Feb 2019 23:37:44 -0600, Parav Pandit wrote: > > Requirements for above use cases: > > > > 1. We need a generic user interface & core APIs to create sub devices > > from a parent pci device but should be generic enough for other parent > > devices 2. Interface should be vendor agnostic 3. User should be able > > to set device params at creation time 4. In future if needed, tool > > should be able to create passthrough device to map to a virtual > > machine > > Like a mediated device? > Yes. > https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt > https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/Mediated- > Devices-Better-Userland-IO.pdf > > Other than pass-through it is entirely unclear to me why you'd need a bus. > (Or should I say VM pass through or DPDK?) Could you clarify why the need > for a bus? > A bus follow standard linux kernel device driver model to attach a driver to specific device. Platform device with my limited understanding looks a hack/abuse of it based on documentation [1], but it can possibly be an alternative to bus if it looks fine to Greg and others. > My thinking is that we should allow spawning subports in devlink and if user > specifies "passthrough" the device spawned would be an mdev. > devlink device is much more comprehensive way to create sub-devices than sub-ports for at least below reasons. 1. devlink device already defines device->port relation which enables to create multiport device. subport breaks that. 2. With bus model, it enables us to load driver of same vendor or generic one such a vfio in future. 3. Devices live on the bus, mapping a subport to 'struct device' is not intuitive. 4. sub-device allows to use existing devlink port, registers, health infrastructure to sub devices, which otherwise need to be duplicated for ports. 5. Even though current devlink devices are networking devices, there is nothing restricts it to be that way. So subport is a restricted view. 6. devlink device already covers port sub-object, hence creating devlink device is desired. > > 5. A device can have multiple ports > > What does this mean, in practice? You want to spawn a subdev which can > access both ports? That'd be for RDMA use cases, more than Ethernet, > right? (Just clarifying :)) > Yep, you got it right. :-) > > So how is it done? > > -- > > (a) user in control > > To address above requirements, a generic tool iproute2/devlink is > > extended for sub device's life cycle. > > However a devlink tool and its kernel counter part is not sufficient > > to create protocol agnostic devices on a existing PCI bus. > > "Protocol agnostic"?... What does that mean? > Devlink works on bus,device model. It doesn't matter what class of device is. For example, for pci class can be anything. So newly created sub-devices are not limited to netdev/rdma devices. Its agnostic to protocol. More importantly, we don't want to create these sub-devices who bus type is 'pci'. Because as described below, PCI has its addressing scheme and pci bus must not have mix-n match devices. So probably better wording should be, 'a devlink tool and its kernel counterpart is not sufficient to create sub-devices of same class as that of PCI device. > > (b) subdev bus > > A given bus defines well defined addressing scheme. Creating sub > > devices on existing PCI bus with a different naming scheme is just weird. > > So, creating well named devices on appropriate bus is desired. > > What's that address scheme you're referring to, you seem to assign IDs in > sequence? > Yes. a device on subdev bus follows standard linux driver model based id assignment scheme = u32. And devices are well named as 'subdev0'. Prefix + id as the default scheme of core driver model. > > > > Given that, these are user created devices for a given hardware and in > > absence of a central entity like PCISIG to assign vendor and device > > ids, A unique vendor and device id are maintained as enum in > > include/linux/subdev_ids.h. > > Why do we need IDs? The sysfs hierarchy isn't sufficient? > Do we need a driver to match on those again? Is it going to be a different > driver? > IDs are used to match driver against the created device. It can be same or different driver. Even in same driver case, it provides a clear code separation for creating sub-devices and their respective one or more protocol devices (netdev, rep-netdev, rdma ..) > > subdev bus device names follow default device naming scheme of Linux > > kernel. It is done as 'subdev' such as, subdev0, subdev3.
[PATCH V6 1/2] watchdog: imx_sc: Add i.MX system controller watchdog support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and watchdog etc..
This patch adds i.MX system controller watchdog driver support,
watchdog operation needs to be done in secure EL3 mode via
ARM-Trusted-Firmware, using SMC call, CPU will trap into
ARM-Trusted-Firmware and then it will request system controller
to do watchdog operation via IPC.
Signed-off-by: Anson Huang
---
Changes since V5:
- add "fsl,imx-scu" node check in imx_sc_wdt_init() function to decide
whether to instantiate
the imx scu watchdog platform driver/device.
---
drivers/watchdog/Kconfig | 14 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx_sc_wdt.c | 204 ++
3 files changed, 219 insertions(+)
create mode 100644 drivers/watchdog/imx_sc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 65c3c42..a6bfa54 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -625,6 +625,20 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config IMX_SC_WDT
+ tristate "IMX SC Watchdog"
+ depends on IMX_SCU
+ depends on HAVE_ARM_SMCCC
+ select WATCHDOG_CORE
+ help
+ This is the driver for the system controller watchdog
+ on the NXP i.MX SoCs with system controller inside.
+ If you have one of these processors and wish to have
+ watchdog support enabled, say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx_sc_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 4e78a8c..0c9da63 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
new file mode 100644
index 000..df8b3e3
--- /dev/null
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_TIMEOUT 60
+/*
+ * Software timer tick implemented in scfw side, support 10ms to 0x ms
+ * in theory, but for normal case, 1s~128s is enough, you can change this max
+ * value in case it's not enough.
+ */
+#define MAX_TIMEOUT 128
+
+#define IMX_SIP_TIMER 0xC202
+#define IMX_SIP_TIMER_START_WDOG 0x01
+#define IMX_SIP_TIMER_STOP_WDOG0x02
+#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03
+#define IMX_SIP_TIMER_PING_WDOG0x04
+#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05
+#define IMX_SIP_TIMER_GET_WDOG_STAT0x06
+#define IMX_SIP_TIMER_SET_PRETIME_WDOG 0x07
+
+#define SC_TIMER_WDOG_ACTION_PARTITION 0
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned int timeout = DEFAULT_TIMEOUT;
+module_param(timeout, uint, );
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+__MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+static struct platform_device *imx_sc_wdt_pdev;
+
+static int imx_sc_wdt_ping(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_PING_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return 0;
+}
+
+static int imx_sc_wdt_start(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_START_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+ if (res.a0)
+ return -EACCES;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_WDOG_ACT,
+ SC_TIMER_WDOG_ACTION_PARTITION,
+ 0, 0, 0, 0, 0, );
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_stop(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_STOP_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct arm_smccc_res res;
+
+
[PATCH V6 2/2] arm64: defconfig: add support for i.MX system controller watchdog
Enable CONFIG_IMX_SC_WDT as module to support i.MX system controller watchdog. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2d9c390..690f4ba 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -427,6 +427,7 @@ CONFIG_WATCHDOG=y CONFIG_ARM_SP805_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_IMX_SC_WDT=m CONFIG_MESON_GXBB_WATCHDOG=m CONFIG_MESON_WATCHDOG=m CONFIG_RENESAS_WDT=y -- 2.7.4
[PATCH] x86/boot: Fix incorrect ifdeffery scope
The declarations related to immovable memory handling are put out of
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/misc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd13655e0f9b..8bbaf362855c 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -120,8 +120,6 @@ static inline void console_init(void)
void set_sev_encryption_mask(void);
-#endif
-
/* acpi.c */
#ifdef CONFIG_ACPI
acpi_physical_address get_rsdp_addr(void);
@@ -135,3 +133,5 @@ int count_immovable_mem_regions(void);
#else
static inline int count_immovable_mem_regions(void) { return 0; }
#endif
+
+#endif
--
2.17.2
Re: A quesiton about commit 3a63f70bf4c3
On 03/04/19 at 09:27am, Chao Fan wrote: > On Fri, Mar 01, 2019 at 02:06:31PM +0800, Baoquan He wrote: > > > >Hi Chao, > Hi Baoquan, > > Sorry for late reply, I was away from keyboard last Friday. > Your change looks good, I think you can format it as a real PATCH. Thx, sent.
Re: [RFT][PATCH 0/2] cpufreq: intel_pstate: Handle _PPC updates on global turbo disable/enable
On Sun, 2019-03-03 at 22:51 +0100, Rafael J. Wysocki wrote: > On Sun, Mar 3, 2019 at 10:20 PM Srinivas Pandruvada > wrote: > > > > On Sun, 2019-03-03 at 18:03 +0100, Rafael J. Wysocki wrote: > > > On Fri, Mar 1, 2019 at 6:39 PM Srinivas Pandruvada > > > wrote: > > > > > > > > On Fri, 2019-03-01 at 13:43 +0100, Rafael J. Wysocki wrote: > > > > > Hi All, > > > > > > > > > > This is how I would fix the issue reported in BZ 200759 (see > > > > > thisdev > > > > > patch series > > > > > from Yu too: > > > > > https://marc.info/?l=linux-pm=155137672924029=2) > > > > > . > > > > > > > > > > Patch [1/2] causes intel_pstate to update all policies if it > > > > > gets > > > > > a > > > > > _PPC change > > > > > notification and sees a global turbo disable/enable change. > > > > > > > > > > Patch [2/2] makes it update cpuinfo.max_freq for all policies > > > > > in > > > > > those cases. > > > > > > > > > > The patches here have not been tested yet, so testing would > > > > > be > > > > > much > > > > > appreciated. > > > > > > > > > > Of course, comments are welcome too! > > > > > > > > This is the only platform, someone reported such issue. > > > > > > I don't think this matters. > > > > > > First, it doesn't mean that no other problems have this problem. > > > > > > Second, the current handling of > > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE > > > changes in intel_pstate is not sufficient if the changes is from > > > set > > > to unset anyway. > > > > Any platform with HWP, you can't even notify of this change. So any > > platform beyond SKL is not useful. > > Do you mean that HWP platforms don't supply _PPS (as a rule) and so > they don't send _PPC notifications? Is there anything they do > instead > of it? There are other methods like PL1 budget limit for such cases. FW can just change the config TDP level. > > That's fair enough, but the point is that the driver doesn'dev_t do > the > right thing even if the platform does send a _PPC notification. _PPC notification is to indicate levels in _PSS not to disable/enable turbo via IA32_MISC_*. The platform could have just set _PPC to 1 or to TAR-1. Here _PPC is sent for somthing more than just changing _PSS max level. Do we have bug in if _PPC just changes performance level? > > > Fixing is always good :-) > > Well, I can only agree with that ...
Re: [f2fs-dev] [PATCH] f2fs: fix to do sanity check with inode.i_inline_xattr_size
On Fri, Mar 01, 2019 at 03:38:05PM +0800, Chao Yu wrote:
> As Paul Bandha reported in bugzilla:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202709
>
> When I run the poc on the mounted f2fs img I get a buffer overflow in
> read_inline_xattr due to there being no sanity check on the value of
> i_inline_xattr_size.
>
> I created the img by just modifying the value of i_inline_xattr_size
> in the inode:
>
> i_name[test1.txt]
> i_ext: fofs:0 blkaddr:0 len:0
> i_extra_isize [0x 18 : 24]
> i_inline_xattr_size [0x : 65535]
> i_addr[ofs] [0x 0 : 0]
>
> mkdir /mnt/f2fs
> mount ./f2fs1.img /mnt/f2fs
> gcc poc.c -o poc
> ./poc
>
> int main() {
> int y = syscall(SYS_listxattr, "/mnt/f2fs/test1.txt", NULL, 0);
> printf("ret %d", y);
> printf("errno: %d\n", errno);
>
> }
>
> BUG: KASAN: slab-out-of-bounds in read_inline_xattr+0x18f/0x260
> Read of size 262140 at addr 88011035efd8 by task f2fs1poc/3263
>
> CPU: 0 PID: 3263 Comm: f2fs1poc Not tainted 4.18.0-custom #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
> Call Trace:
> dump_stack+0x71/0xab
> print_address_description+0x83/0x250
> kasan_report+0x213/0x350
> memcpy+0x1f/0x50
> read_inline_xattr+0x18f/0x260
> read_all_xattrs+0xba/0x190
> f2fs_listxattr+0x9d/0x3f0
> listxattr+0xb2/0xd0
> path_listxattr+0x93/0xe0
> do_syscall_64+0x9d/0x220
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Let's add sanity check for inode.i_inline_xattr_size during f2fs_iget()
> to avoid this issue.
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/inode.c | 14 ++
> fs/f2fs/super.c | 7 ++-
> fs/f2fs/xattr.h | 9 +
> 3 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index bec52961630b..b132fe2ff779 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -14,6 +14,7 @@
> #include "f2fs.h"
> #include "node.h"
> #include "segment.h"
> +#include "xattr.h"
>
> #include
>
> @@ -248,6 +249,19 @@ static bool sanity_check_inode(struct inode *inode,
> struct page *node_page)
> return false;
> }
>
> + if (f2fs_has_extra_attr(inode) &&
> + f2fs_sb_has_flexible_inline_xattr(sbi) &&
> + (fi->i_inline_xattr_size < MIN_INLINE_XATTR_SIZE ||
> + fi->i_inline_xattr_size > MAX_INLINE_XATTR_SIZE)) {
> + set_sbi_flag(sbi, SBI_NEED_FSCK);
> + f2fs_msg(sbi->sb, KERN_WARNING,
> + "%s: inode (ino=%lx) has corrupted "
> + "i_inline_xattr_size: %d, min: %zu, max: %zu",
> + __func__, inode->i_ino, fi->i_inline_xattr_size,
> + MIN_INLINE_XATTR_SIZE, MAX_INLINE_XATTR_SIZE);
> + return false;
> + }
> +
> if (F2FS_I(inode)->extent_tree) {
> struct extent_info *ei = _I(inode)->extent_tree->largest;
>
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 42eb5c86330a..9184b7524c03 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -835,12 +835,9 @@ static int parse_options(struct super_block *sb, char
> *options)
> return -EINVAL;
> }
> if (F2FS_OPTION(sbi).inline_xattr_size <
> - sizeof(struct f2fs_xattr_header) / sizeof(__le32) ||
> + MIN_INLINE_XATTR_SIZE ||
> F2FS_OPTION(sbi).inline_xattr_size >
> - DEF_ADDRS_PER_INODE -
> - F2FS_TOTAL_EXTRA_ATTR_SIZE / sizeof(__le32) -
> - DEF_INLINE_RESERVED_SIZE -
> - MIN_INLINE_DENTRY_SIZE / sizeof(__le32)) {
> + MAX_INLINE_XATTR_SIZE) {
> f2fs_msg(sb, KERN_ERR,
> "inline xattr size is out of range");
> return -EINVAL;
> diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
> index 67db134da0f5..94e8a5eeaae1 100644
> --- a/fs/f2fs/xattr.h
> +++ b/fs/f2fs/xattr.h
> @@ -55,6 +55,8 @@ struct f2fs_xattr_entry {
> #define XATTR_FIRST_ENTRY(ptr) (XATTR_ENTRY(XATTR_HDR(ptr) + 1))
> #define XATTR_ROUND (3)
>
> +#define XATTR_HDR_SIZE (sizeof(struct f2fs_xattr_header))
> +
> #define XATTR_ALIGN(size)(((size) + XATTR_ROUND) & ~XATTR_ROUND)
>
> #define ENTRY_SIZE(entry) (XATTR_ALIGN(sizeof(struct f2fs_xattr_entry) + \
> @@ -78,6 +80,13 @@ struct f2fs_xattr_entry {
> sizeof(struct f2fs_xattr_header) - \
> sizeof(struct f2fs_xattr_entry))
>
> +#define MAX_INLINE_XATTR_SIZE(XATTR_HDR_SIZE / sizeof(__le32))
I think this should be MIN_INLINE_XATTR_SIZE.
> +#define MIN_INLINE_XATTR_SIZE
[PATCH 02/20] docs/zh_CN: move process related docs into process dir
Much process documents spread here isn't neat. It's good to put them together
in their directory: process
So create 'process' directory and move docs:
email-clients stable_kernel_rules stable_api_nosense
submittingpatches submittingdrivers HOWTO
volatile-considered-harmful
there.
Signed-off-by: Alex Shi
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Coly Li
---
Documentation/translations/zh_CN/{ => process}/HOWTO | 0
Documentation/translations/zh_CN/{ => process}/SubmittingDrivers | 0
Documentation/translations/zh_CN/{ => process}/SubmittingPatches | 0
Documentation/translations/zh_CN/{ => process}/coding-style.rst | 0
Documentation/translations/zh_CN/{ => process}/email-clients.txt | 0
Documentation/translations/zh_CN/{ => process}/magic-number.txt | 0
.../translations/zh_CN/{ => process}/stable_api_nonsense.txt | 0
.../translations/zh_CN/{ => process}/stable_kernel_rules.txt | 0
.../zh_CN/{ => process}/volatile-considered-harmful.txt | 0
9 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/{ => process}/HOWTO (100%)
rename Documentation/translations/zh_CN/{ => process}/SubmittingDrivers (100%)
rename Documentation/translations/zh_CN/{ => process}/SubmittingPatches (100%)
rename Documentation/translations/zh_CN/{ => process}/coding-style.rst (100%)
rename Documentation/translations/zh_CN/{ => process}/email-clients.txt (100%)
rename Documentation/translations/zh_CN/{ => process}/magic-number.txt (100%)
rename Documentation/translations/zh_CN/{ => process}/stable_api_nonsense.txt
(100%)
rename Documentation/translations/zh_CN/{ => process}/stable_kernel_rules.txt
(100%)
rename Documentation/translations/zh_CN/{ =>
process}/volatile-considered-harmful.txt (100%)
diff --git a/Documentation/translations/zh_CN/HOWTO
b/Documentation/translations/zh_CN/process/HOWTO
similarity index 100%
rename from Documentation/translations/zh_CN/HOWTO
rename to Documentation/translations/zh_CN/process/HOWTO
diff --git a/Documentation/translations/zh_CN/SubmittingDrivers
b/Documentation/translations/zh_CN/process/SubmittingDrivers
similarity index 100%
rename from Documentation/translations/zh_CN/SubmittingDrivers
rename to Documentation/translations/zh_CN/process/SubmittingDrivers
diff --git a/Documentation/translations/zh_CN/SubmittingPatches
b/Documentation/translations/zh_CN/process/SubmittingPatches
similarity index 100%
rename from Documentation/translations/zh_CN/SubmittingPatches
rename to Documentation/translations/zh_CN/process/SubmittingPatches
diff --git a/Documentation/translations/zh_CN/coding-style.rst
b/Documentation/translations/zh_CN/process/coding-style.rst
similarity index 100%
rename from Documentation/translations/zh_CN/coding-style.rst
rename to Documentation/translations/zh_CN/process/coding-style.rst
diff --git a/Documentation/translations/zh_CN/email-clients.txt
b/Documentation/translations/zh_CN/process/email-clients.txt
similarity index 100%
rename from Documentation/translations/zh_CN/email-clients.txt
rename to Documentation/translations/zh_CN/process/email-clients.txt
diff --git a/Documentation/translations/zh_CN/magic-number.txt
b/Documentation/translations/zh_CN/process/magic-number.txt
similarity index 100%
rename from Documentation/translations/zh_CN/magic-number.txt
rename to Documentation/translations/zh_CN/process/magic-number.txt
diff --git a/Documentation/translations/zh_CN/stable_api_nonsense.txt
b/Documentation/translations/zh_CN/process/stable_api_nonsense.txt
similarity index 100%
rename from Documentation/translations/zh_CN/stable_api_nonsense.txt
rename to Documentation/translations/zh_CN/process/stable_api_nonsense.txt
diff --git a/Documentation/translations/zh_CN/stable_kernel_rules.txt
b/Documentation/translations/zh_CN/process/stable_kernel_rules.txt
similarity index 100%
rename from Documentation/translations/zh_CN/stable_kernel_rules.txt
rename to Documentation/translations/zh_CN/process/stable_kernel_rules.txt
diff --git a/Documentation/translations/zh_CN/volatile-considered-harmful.txt
b/Documentation/translations/zh_CN/process/volatile-considered-harmful.txt
similarity index 100%
rename from Documentation/translations/zh_CN/volatile-considered-harmful.txt
rename to
Documentation/translations/zh_CN/process/volatile-considered-harmful.txt
--
2.19.1.856.g8858448bb
[PATCH 11/20] docs/zh_CN: rename email-clients.txt as email-clients.rst
Make it available for html etc docs.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../zh_CN/process/{email-clients.txt => email-clients.rst}| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{email-clients.txt =>
email-clients.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/email-clients.txt
b/Documentation/translations/zh_CN/process/email-clients.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/email-clients.txt
rename to Documentation/translations/zh_CN/process/email-clients.rst
--
2.19.1.856.g8858448bb
[PATCH 08/20] docs/zh_CN: format the submitting-patches doc to rst
And remove Enghlish explainations in the docs, which it isn't necessary in Chinese doc. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: TripleX Chung Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../zh_CN/process/submitting-patches.rst | 36 +++ 1 file changed, 13 insertions(+), 23 deletions(-) diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index e9098da8f1a4..2a2989733c8d 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -1,31 +1,21 @@ -Chinese translated version of Documentation/process/submitting-patches.rst +.. _cn_process_submittingpatches: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Chinese maintainer: TripleX Chung -- -Documentation/process/submitting-patches.rst 的中文翻译 +:Original: :ref:`Documentation/process/submitting-patches.rst ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: -中文版维护者： 钟宇 TripleX Chung -中文版翻译者： 钟宇 TripleX Chung -中文版校译者： 李阳 Li Yang - 王聪 Wang Cong +中文版维护者： 钟宇 TripleX Chung +中文版翻译者： 钟宇 TripleX Chung +中文版校译者： 李阳 Li Yang + 王聪 Wang Cong -以下为正文 -- - 如何让你的改动进入内核 - 或者 - 获得亲爱的 Linus Torvalds 的关注和处理 --- +如何让你的改动进入内核 +== 对于想要将改动提交到 Linux 内核的个人或者公司来说，如果不熟悉“规矩”， 提交的流程会让人畏惧。本文档收集了一系列建议，这些建议可以大大的提高你 @@ -35,12 +25,12 @@ Documentation/process/submitting-patches.rst 的中文翻译 Documentation/process/submitting-drivers.rst 。 --- +--- 第一节 - 创建并发送你的改动 --- +--- 1) "diff -up" +- 使用 "diff -up" 或者 "diff -uprN" 来创建补丁。 -- 2.19.1.856.g8858448bb
[PATCH 07/20] docs/zh_CN: rename SubmittingPatches for html links
renamed:Documentation/translations/zh_CN/process/SubmittingPatches
-> Documentation/translations/zh_CN/process/submitting-patches.rst
For htmldoc links. And will change the doc format to rst.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: TripleX Chung
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../zh_CN/process/{SubmittingPatches => submitting-patches.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{SubmittingPatches =>
submitting-patches.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/SubmittingPatches
b/Documentation/translations/zh_CN/process/submitting-patches.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/SubmittingPatches
rename to Documentation/translations/zh_CN/process/submitting-patches.rst
--
2.19.1.856.g8858448bb
[PATCH 12/20] docs/zh_CN: do rst format for email-clients.rst
Make it readble as rst format. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../zh_CN/process/email-clients.rst | 53 --- 1 file changed, 22 insertions(+), 31 deletions(-) diff --git a/Documentation/translations/zh_CN/process/email-clients.rst b/Documentation/translations/zh_CN/process/email-clients.rst index ec31d97e8d0e..e8641a5899e4 100644 --- a/Documentation/translations/zh_CN/process/email-clients.rst +++ b/Documentation/translations/zh_CN/process/email-clients.rst @@ -1,33 +1,24 @@ -Chinese translated version of Documentation/process/email-clients.rst +.. _cn_email_clients: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Chinese maintainer: Harry Wei -- -Documentation/process/email-clients.rst 的中文翻译 +:Original: :ref:`Documentation/process/email-clients.rst ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: -中文版维护者： 贾威威 Harry Wei -中文版翻译者： 贾威威 Harry Wei -中文版校译者： Yinglin Luan - Xiaochen Wang - yaxinsn - -以下为正文 -- +中文版维护者： 贾威威 Harry Wei +中文版翻译者： 贾威威 Harry Wei +中文版校译者： Yinglin Luan + Xiaochen Wang + yaxinsn Linux邮件客户端配置信息 -== +=== 普通配置 --- + Linux内核补丁是通过邮件被提交的，最好把补丁作为邮件体的内嵌文本。有些维护者 接收附件，但是附件的内容格式应该是"text/plain"。然而，附件一般是不赞成的， 因为这会使补丁的引用部分在评论过程中变的很困难。 @@ -56,7 +47,7 @@ Linux内核补丁是通过邮件被提交的，最好把补丁作为邮件体的 一些邮件客户端提示 --- +-- 这里给出一些详细的MUA配置提示，可以用于给Linux内核发送补丁。这些并不意味是 所有的软件包配置总结。 @@ -64,8 +55,8 @@ Linux内核补丁是通过邮件被提交的，最好把补丁作为邮件体的 TUI = 以文本为基础的用户接口 GUI = 图形界面用户接口 -~~ Alpine (TUI) + 配置选项： 在"Sending Preferences"部分： @@ -76,8 +67,8 @@ Alpine (TUI) 当写邮件时，光标应该放在补丁会出现的地方，然后按下CTRL-R组合键，使指定的 补丁文件嵌入到邮件中。 -~~ Evolution (GUI) +~~~ 一些开发者成功的使用它发送补丁 @@ -89,8 +80,8 @@ Evolution (GUI) 你还可以"diff -Nru old.c new.c | xclip"，选择Preformat，然后使用中间键进行粘帖。 -~~ Kmail (GUI) +~~~ 一些开发者成功的使用它发送补丁。 @@ -118,13 +109,13 @@ display"，这样内嵌附件更容易让读者看到。 并且希望这将会被处理。邮件是以只针对某个用户可读写的权限被保存的，所以如果你想把邮件复制到其他地方， 你不得不把他们的权限改为组或者整体可读。 -~~ Lotus Notes (GUI) +~ 不要使用它。 -~~ Mutt (TUI) +~~ 很多Linux开发人员使用mutt客户端，所以证明它肯定工作的非常漂亮。 @@ -146,8 +137,8 @@ Mutt不自带编辑器，所以不管你使用什么编辑器都不应该带有 它应该以默认设置的形式工作。 然而，把"send_charset"设置为"us-ascii::utf-8"也是一个不错的主意。 -~~ Pine (TUI) +~~ Pine过去有一些空格删减问题，但是这些现在应该都被修复了。 @@ -158,8 +149,8 @@ Pine过去有一些空格删减问题，但是这些现在应该都被修复了 - "no-strip-whitespace-before-send"选项也是需要的。 -~~ Sylpheed (GUI) +~~ - 内嵌文本可以很好的工作（或者使用附件）。 - 允许使用外部的编辑器。 @@ -168,8 +159,8 @@ Sylpheed (GUI) - 在组成窗口中有一个很有用的ruler bar。 - 给地址本中添加地址就不会正确的了解显示名。 -~~ Thunderbird (GUI) +~ 默认情况下，thunderbird很容易损坏文本，但是还有一些方法可以强制它变得更好。 @@ -191,13 +182,13 @@ Thunderbird (GUI) $EDITOR来读取或者合并补丁到文本中。要实现它，可以下载并且安装这个扩展，然后添加一个使用它的 按键View->Toolbars->Customize...最后当你书写信息的时候仅仅点击它就可以了。 -~~ TkRat (GUI) +~~~ 可以使用它。使用"Insert file..."或者外部的编辑器。 -~~ Gmail (Web GUI) +~~~ 不要使用它发送补丁。 -- 2.19.1.856.g8858448bb
[PATCH 03/20] docs/zh_CN: change Chinese index to know process dir
And add some description translation in index file. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- Documentation/translations/zh_CN/index.rst | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 75956d669962..dbc77a646530 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -3,10 +3,19 @@ \renewcommand\thesection* \renewcommand\thesubsection* -Chinese translations - +中文翻译 + + +这些手册包含有关如何开发内核的整体信息。内核社区非常庞大，一年下来有数千名开发 +人员做出贡献。 与任何大型社区一样，知道如何完成任务将使得更改合并的过程变得更 +加容易。 .. toctree:: - :maxdepth: 1 + :maxdepth: 2 + + process/index + +目录和表格 +== - coding-style +* :ref:`genindex` -- 2.19.1.856.g8858448bb
[PATCH 17/20] docs/zh_CN: rename magic-numbers as rst doc
to Make it available in html etc doc making
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Jia Wei Wei
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../zh_CN/process/{magic-number.txt => magic-number.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{magic-number.txt =>
magic-number.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/magic-number.txt
b/Documentation/translations/zh_CN/process/magic-number.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/magic-number.txt
rename to Documentation/translations/zh_CN/process/magic-number.rst
--
2.19.1.856.g8858448bb
[PATCH 10/20] docs/zh_CN: rst format change for stable-kernel-rules
to Make it readble with rst format. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: TripleX Chung Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../zh_CN/process/stable-kernel-rules.rst | 32 +-- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/Documentation/translations/zh_CN/process/stable-kernel-rules.rst b/Documentation/translations/zh_CN/process/stable-kernel-rules.rst index db4ba5a0c39a..425d06f99ac2 100644 --- a/Documentation/translations/zh_CN/process/stable-kernel-rules.rst +++ b/Documentation/translations/zh_CN/process/stable-kernel-rules.rst @@ -1,31 +1,26 @@ -Chinese translated version of Documentation/process/stable-kernel-rules.rst +.. _cn_stable_kernel_rules: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Chinese maintainer: TripleX Chung -- -Documentation/process/stable-kernel-rules.rst 的中文翻译 +:Original: :ref:`Documentation/process/stable-kernel-rules.rst ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: +中文版维护者： 钟宇 TripleX Chung +中文版翻译者： 钟宇 TripleX Chung +中文版校译者： +- 李阳 Li Yang +- Kangkai Yin -中文版维护者： 钟宇 TripleX Chung -中文版翻译者： 钟宇 TripleX Chung -中文版校译者： 李阳 Li Yang - Kangkai Yin - -以下为正文 -- +所有你想知道的事情 - 关于linux稳定版发布 + 关于Linux 2.6稳定版发布，所有你想知道的事情。 关于哪些类型的补丁可以被接收进入稳定版代码树，哪些不可以的规则： + - 必须是显而易见的正确，并且经过测试的。 - 连同上下文，不能大于100行。 @@ -41,6 +36,7 @@ Documentation/process/stable-kernel-rules.rst 的中文翻译 - 必须遵循Documentation/process/submitting-patches.rst里的规则。 向稳定版代码树提交补丁的过程： +-- - 在确认了补丁符合以上的规则后，将补丁发送到sta...@vger.kernel.org。 - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收 @@ -49,6 +45,7 @@ Documentation/process/stable-kernel-rules.rst 的中文翻译 - 安全方面的补丁不要发到这个列表，应该发送到secur...@kernel.org。 审查周期： +-- - 当稳定版的维护者决定开始一个审查周期，补丁将被发送到审查委员会，以 及被补丁影响的领域的维护者（除非提交者就是该领域的维护者）并且抄送 @@ -63,4 +60,5 @@ Documentation/process/stable-kernel-rules.rst 的中文翻译 通常的审查周期。请联系内核安全小组以获得关于这个过程的更多细节。 审查委员会： + - 由一些自愿承担这项任务的内核开发者，和几个非志愿的组成。 -- 2.19.1.856.g8858448bb
[PATCH 15/20] docs/zh_CN: rename SubmittingDrivers
Rename the file to make it available in html etc docs making.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Yang
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../zh_CN/process/{SubmittingDrivers => submitting-drivers.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{SubmittingDrivers =>
submitting-drivers.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/SubmittingDrivers
b/Documentation/translations/zh_CN/process/submitting-drivers.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/SubmittingDrivers
rename to Documentation/translations/zh_CN/process/submitting-drivers.rst
--
2.19.1.856.g8858448bb
[PATCH 16/20] docs/zh_CN: format submitting drivers as rst
to Make it readble for html etc docs making. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Yang Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../zh_CN/process/submitting-drivers.rst | 30 +++ 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/Documentation/translations/zh_CN/process/submitting-drivers.rst b/Documentation/translations/zh_CN/process/submitting-drivers.rst index 15e73562f710..c90ab5ae233d 100644 --- a/Documentation/translations/zh_CN/process/submitting-drivers.rst +++ b/Documentation/translations/zh_CN/process/submitting-drivers.rst @@ -1,30 +1,22 @@ -Chinese translated version of Documentation/process/submitting-drivers.rst +.. _cn_submittingdrivers: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Chinese maintainer: Li Yang -- -Documentation/process/submitting-drivers.rst 的中文翻译 +:Original: :ref:`Documentation/process/submitting-drivers.rst + ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: -中文版维护者： 李阳 Li Yang -中文版翻译者： 李阳 Li Yang -中文版校译者： 陈琦 Maggie Chen - 王聪 Wang Cong - 张巍 Zhang Wei - -以下为正文 -- +中文版维护者： 李阳 Li Yang +中文版翻译者： 李阳 Li Yang +中文版校译者： 陈琦 Maggie Chen + 王聪 Wang Cong + 张巍 Zhang Wei 如何向 Linux 内核提交驱动程序 -- += 这篇文档将会解释如何向不同的内核源码树提交设备驱动程序。请注意，如果你感 兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(http://www.xfree86.org/) -- 2.19.1.856.g8858448bb
[PATCH 14/20] docs/zh_CN: volatile doc format changes
make it readble as rst format for html etc doc making. Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Bryan Wu Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../process/volatile-considered-harmful.rst | 35 --- 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst index 475125967197..48b32ce58ef1 100644 --- a/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst +++ b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst @@ -1,30 +1,23 @@ -Chinese translated version of Documentation/process/volatile-considered-harmful.rst +.. _cn_volatile_considered_harmful: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Maintainer: Jonathan Corbet -Chinese maintainer: Bryan Wu -- -Documentation/process/volatile-considered-harmful.rst 的中文翻译 +:Original: :ref:`Documentation/process/volatile-considered-harmful.rst + ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: -英文版维护者： Jonathan Corbet -中文版维护者： 伍鹏 Bryan Wu -中文版翻译者： 伍鹏 Bryan Wu -中文版校译者： 张汉辉 Eugene Teo - 杨瑞 Dave Young -以下为正文 -- +英文版维护者： Jonathan Corbet +中文版维护者： 伍鹏 Bryan Wu +中文版翻译者： 伍鹏 Bryan Wu +中文版校译者： 张汉辉 Eugene Teo + 杨瑞 Dave Young + 时奎亮 Alex Shi 为什么不应该使用“volatile”类型 --- +== C程序员通常认为volatile表示某个变量可以在当前执行的线程之外被改变；因此，在内核 中用到共享数据结构时，常常会有C程序员喜欢使用volatile这类变量。换句话说，他们经 @@ -41,7 +34,7 @@ C程序员通常认为volatile表示某个变量可以在当前执行的线程 必要再使用volatile。如果仍然必须使用volatile，那么几乎可以肯定在代码的某处有一 个bug。在正确设计的内核代码中，volatile能带来的仅仅是使事情变慢。 -思考一下这段典型的内核代码： +思考一下这段典型的内核代码:: spin_lock(_lock); do_something_on(_data); @@ -66,7 +59,7 @@ volatile的存储类型最初是为那些内存映射的I/O寄存器而定义。 是必需的。 另一种引起用户可能使用volatile的情况是当处理器正忙着等待一个变量的值。正确执行一 -个忙等待的方法是： +个忙等待的方法是:: while (my_variable != what_i_want) cpu_relax(); -- 2.19.1.856.g8858448bb
[PATCH 04/20] docs/zh_CN: add index file into process dir
Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../translations/zh_CN/process/index.rst | 55 +++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/translations/zh_CN/process/index.rst diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst new file mode 100644 index ..2e2fb0b2879b --- /dev/null +++ b/Documentation/translations/zh_CN/process/index.rst @@ -0,0 +1,55 @@ +.. raw:: latex + + \renewcommand\thesection* + \renewcommand\thesubsection* + +.. include:: ../disclaimer-zh_CN.rst + +:Original: :ref:`Documentation/process/index.rst ` +:Translator: Alex Shi + +.. _cn_process_index: + +与Linux 内核社区一起工作 + + +那么你想成为Linux内核开发人员？ 欢迎！ 不但从技术意义上讲有很多关于内核的知识 +需要学，而且了解我们社区的工作方式也很重要。 阅读这些文章可以让您以更轻松地, +麻烦最少的方式将更改合并到内核。 + +以下是每位开发人员应阅读的基本指南。 + +.. toctree:: + :maxdepth: 1 + + howto + submitting-patches + coding-style + email-clients + +其它大多数开发人员感兴趣的社区指南： + + +.. toctree:: + :maxdepth: 1 + + submitting-drivers + stable-api-nonsense + stable-kernel-rules + kernel-docs + +这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里 + +.. toctree:: + :maxdepth: 1 + + adding-syscalls + magic-number + volatile-considered-harmful + +.. only:: subproject and html + + 目录 + + + * :ref:`genindex` -- 2.19.1.856.g8858448bb
[PATCH 06/20] docs/zh_CN: howto format changes
also with few contents changes Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Yang Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li --- .../translations/zh_CN/process/howto.rst | 37 --- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 5f6d09edc9ac..e4e800591ae9 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -1,32 +1,23 @@ -Chinese translated version of Documentation/process/howto.rst +.. _cn_process_howto: -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Maintainer: Greg Kroah-Hartman -Chinese maintainer: Li Yang -- -Documentation/process/howto.rst 的中文翻译 +:Original: :ref:`Documentation/process/howto.rst ` 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +译存在问题，请联系中文版维护者:: -英文版维护者： Greg Kroah-Hartman -中文版维护者： 李阳 Li Yang -中文版翻译者： 李阳 Li Yang -中文版校译者： 钟宇 TripleX Chung - 陈琦 Maggie Chen - 王聪 Wang Cong - -以下为正文 -- +英文版维护者： Greg Kroah-Hartman +中文版维护者： 李阳 Li Yang +中文版翻译者： 李阳 Li Yang +中文版校译者: + 钟宇 TripleX Chung + 陈琦 Maggie Chen + 王聪 Wang Cong 如何参与Linux内核开发 -- += 这是一篇将如何参与Linux内核开发的相关问题一网打尽的终极秘笈。它将指导你 成为一名Linux内核开发者，并且学会如何同Linux内核开发社区合作。它尽可能不 @@ -114,6 +105,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 "The Perfect Patch" http://www.ozlabs.org/~akpm/stuff/tpp.txt "Linux kernel patch submission format" + http://linux.yyz.us/patch-format.html Documentation/process/stable-api-nonsense.rst @@ -519,7 +511,8 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 很多人已经做到了，而他们都曾经和现在的你站在同样的起点上。 +感谢 + 感谢Paolo Ciarrocchi允许“开发流程”部分基于他所写的文章 (http://www.kerneltravel.net/newbie/2.6-development_process)，感谢Randy Dunlap和Gerrit Huizenga完善了应该说和不该说的列表。感谢Pat Mochel, Hanna -- 2.19.1.856.g8858448bb
[PATCH 09/20] docs/zh_CN: rename stable_kernel_rules doc
This patch renamed stable_kernel_rules.txt to stable-kernel-rules.rst
Make it available in htmldocs making.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: TripleX Chung
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../process/{stable_kernel_rules.txt => stable-kernel-rules.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{stable_kernel_rules.txt =>
stable-kernel-rules.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/stable_kernel_rules.txt
b/Documentation/translations/zh_CN/process/stable-kernel-rules.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/stable_kernel_rules.txt
rename to Documentation/translations/zh_CN/process/stable-kernel-rules.rst
--
2.19.1.856.g8858448bb
[PATCH 19/20] docs/zh_CN: rename stable_api_nonsense.txt as stable-api-nonsense.rst
make it available in html etc doc making
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: TripleX Chung
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../process/{stable_api_nonsense.txt => stable-api-nonsense.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{stable_api_nonsense.txt =>
stable-api-nonsense.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/stable_api_nonsense.txt
b/Documentation/translations/zh_CN/process/stable-api-nonsense.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/stable_api_nonsense.txt
rename to Documentation/translations/zh_CN/process/stable-api-nonsense.rst
--
2.19.1.856.g8858448bb
[PATCH 05/20] docs/zh_CN: rename HOWTO into process directory
Make it available in htmldocs
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Yang
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
Documentation/translations/zh_CN/process/{HOWTO => howto.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/translations/zh_CN/process/{HOWTO => howto.rst} (100%)
diff --git a/Documentation/translations/zh_CN/process/HOWTO
b/Documentation/translations/zh_CN/process/howto.rst
similarity index 100%
rename from Documentation/translations/zh_CN/process/HOWTO
rename to Documentation/translations/zh_CN/process/howto.rst
--
2.19.1.856.g8858448bb
[PATCH 13/20] docs/zh_CN: rename volatile-consider-harmful doc
Make it available for html etc docs making.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Bryan Wu
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
...ile-considered-harmful.txt => volatile-considered-harmful.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename
Documentation/translations/zh_CN/process/{volatile-considered-harmful.txt =>
volatile-considered-harmful.rst} (100%)
diff --git
a/Documentation/translations/zh_CN/process/volatile-considered-harmful.txt
b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst
similarity index 100%
rename from
Documentation/translations/zh_CN/process/volatile-considered-harmful.txt
rename to
Documentation/translations/zh_CN/process/volatile-considered-harmful.rst
--
2.19.1.856.g8858448bb
[PATCH 18/20] docs/zh_CN: format the magic-number doc as rst
to Make it readble in html etc doc making. And fix the wrong
translation for 'number' in form.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Jia Wei Wei
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
.../zh_CN/process/magic-number.rst| 210 +-
1 file changed, 104 insertions(+), 106 deletions(-)
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst
b/Documentation/translations/zh_CN/process/magic-number.rst
index 7159cec04090..15c592518194 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -1,33 +1,29 @@
-Chinese translated version of Documentation/process/magic-number.rst
+.. _cn_magicnumbers:
-If you have any comment or update to the content, please post to LKML directly.
-However, if you have problem communicating in English you can also ask the
-Chinese maintainer for help. Contact the Chinese maintainer, if this
-translation is outdated or there is problem with translation.
+.. include:: ../disclaimer-zh_CN.rst
-Chinese maintainer: Jia Wei Wei
--
-Documentation/process/magic-number.rst的中文翻译
+:Original: :ref:`Documentation/process/magic-number.rst `
如果想评论或更新本文的内容，请直接发信到LKML。如果你使用英文交流有困难的话，也可
-以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。
+以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者::
-中文版维护者： 贾威威 Jia Wei Wei
-中文版翻译者： 贾威威 Jia Wei Wei
-中文版校译者： 贾威威 Jia Wei Wei
+中文版维护者： 贾威威 Jia Wei Wei
+中文版翻译者： 贾威威 Jia Wei Wei
+中文版校译者： 贾威威 Jia Wei Wei
+
+Linux 魔术数
+
-以下为正文
--
这个文件是有关当前使用的魔术值注册表。当你给一个结构添加了一个魔术值，你也应该把这个魔术值添加到这个文件，因为我们最好把用于各种结构的魔术值统一起来。
使用魔术值来保护内核数据结构是一个非常好的主意。这就允许你在运行期检查(a)一个结构是否已经被攻击，或者(b)你已经给一个例行程序通过了一个错误的结构。后一种情况特别地有用---特别是当你通过一个空指针指向结构体的时候。tty源码，例如，经常通过特定驱动使用这种方法并且反复地排列特定方面的结构。
-使用魔术值的方法是在结构的开始处声明的，如下：
+使用魔术值的方法是在结构的开始处声明的，如下::
-struct tty_ldisc {
- int magic;
- ...
-};
+struct tty_ldisc {
+ int magic;
+ ...
+};
当你以后给内核添加增强功能的时候，请遵守这条规则！这样就会节省数不清的调试时间，特别是一些古怪的情况，例如，数组超出范围并且重新写了超出部分。遵守这个规则，这些情况可以被快速地，安全地避免。
@@ -58,93 +54,95 @@ struct tty_ldisc {
09 Jul 2003
-魔术名 地址 结构 所在文件
-===
-PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h
-CMAGIC0x0111 user include/linux/a.out.h
-MKISS_DRIVER_MAGIC0x04bf mkiss_channel drivers/net/mkiss.h
-HDLC_MAGIC0x239e n_hdlcdrivers/char/n_hdlc.c
-APM_BIOS_MAGIC0x4101 apm_user arch/x86/kernel/apm_32.c
-CYCLADES_MAGIC0x4359 cyclades_port include/linux/cyclades.h
-DB_MAGIC 0x4442 fc_info
drivers/net/iph5526_novram.c
-DL_MAGIC 0x444d fc_info
drivers/net/iph5526_novram.c
-FASYNC_MAGIC 0x4601 fasync_struct include/linux/fs.h
-FF_MAGIC 0x4646 fc_info
drivers/net/iph5526_novram.c
-ISICOM_MAGIC 0x4d54 isi_port include/linux/isicom.h
-PTY_MAGIC 0x5001drivers/char/pty.c
-PPP_MAGIC 0x5002 ppp include/linux/if_pppvar.h
-SERIAL_MAGIC 0x5301 async_struct include/linux/serial.h
-SSTATE_MAGIC 0x5302 serial_state include/linux/serial.h
-SLIP_MAGIC0x5302 slip drivers/net/slip.h
-STRIP_MAGIC 0x5303 strip drivers/net/strip.c
-X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h
-SIXPACK_MAGIC 0x5304 sixpack
drivers/net/hamradio/6pack.h
-AX25_MAGIC0x5316 ax_disp drivers/net/mkiss.h
-TTY_MAGIC 0x5401 tty_structinclude/linux/tty.h
-MGSL_MAGIC0x5401 mgsl_info drivers/char/synclink.c
-TTY_DRIVER_MAGIC 0x5402 tty_driverinclude/linux/tty_driver.h
-MGSLPC_MAGIC 0x5402 mgslpc_info
drivers/char/pcmcia/synclink_cs.c
-TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h
-USB_SERIAL_MAGIC 0x6702 usb_serial
drivers/usb/serial/usb-serial.h
-FULL_DUPLEX_MAGIC 0x6969
drivers/net/ethernet/dec/tulip/de2104x.c
-USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c
-RFCOMM_TTY_MAGIC 0x6d02net/bluetooth/rfcomm/tty.c
-USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port
drivers/usb/serial/usb-serial.h
-CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h
-RPORT_MAGIC 0x00525001 r_port
[PATCH 00/20] origanize Chinese kernel docs
The following patch aims to upstream kernel doc.
you can view them with the link
http://176.122.172.82/translations/zh_CN/index.html
Or make and review docs on your self box:
make htmldocs SPHINXDIRS=translations/zh_CN
lynx Documentation/output/translations/zh_CN/index.html
Any comments are appreciated!
Cheers!
Alex
---
Alex Shi (20):
docs/zh_CN: add disclaimer file
docs/zh_CN: move process related docs into process dir
docs/zh_CN: change Chinese index to know process dir
docs/zh_CN: add index file into process dir
docs/zh_CN: rename HOWTO into process directory
docs/zh_CN: howto format changes
docs/zh_CN: rename SubmittingPatches for html links
docs/zh_CN: format the submitting-patches doc to rst
docs/zh_CN: rename stable_kernel_rules doc
docs/zh_CN: rst format change for stable-kernel-rules
docs/zh_CN: rename email-clients.txt as email-clients.rst
docs/zh_CN: do rst format for email-clients.rst
docs/zh_CN: rename volatile-consider-harmful doc
docs/zh_CN: volatile doc format changes
docs/zh_CN: rename SubmittingDrivers
docs/zh_CN: format submitting drivers as rst
docs/zh_CN: rename magic-numbers as rst doc
docs/zh_CN: format the magic-number doc as rst
docs/zh_CN: rename stable_api_nonsense.txt as stable-api-nonsense.rst
docs/zh_CN: format stable-api-nonsense
.../translations/zh_CN/disclaimer-zh_CN.rst | 11 ++
Documentation/translations/zh_CN/index.rst| 17 +-
.../translations/zh_CN/magic-number.txt | 153 --
.../zh_CN/{ => process}/coding-style.rst | 0
.../email-clients.rst}| 53 +++---
.../zh_CN/{HOWTO => process/howto.rst}| 37 ++---
.../translations/zh_CN/process/index.rst | 55 +++
.../zh_CN/process/magic-number.rst| 151 +
.../stable-api-nonsense.rst} | 32 ++--
.../stable-kernel-rules.rst} | 32 ++--
.../submitting-drivers.rst} | 30 ++--
.../submitting-patches.rst} | 36 ++---
.../volatile-considered-harmful.rst} | 35 ++--
13 files changed, 334 insertions(+), 308 deletions(-)
create mode 100644 Documentation/translations/zh_CN/disclaimer-zh_CN.rst
delete mode 100644 Documentation/translations/zh_CN/magic-number.txt
rename Documentation/translations/zh_CN/{ => process}/coding-style.rst (100%)
rename Documentation/translations/zh_CN/{email-clients.txt =>
process/email-clients.rst} (82%)
rename Documentation/translations/zh_CN/{HOWTO => process/howto.rst} (95%)
create mode 100644 Documentation/translations/zh_CN/process/index.rst
create mode 100644 Documentation/translations/zh_CN/process/magic-number.rst
rename Documentation/translations/zh_CN/{stable_api_nonsense.txt =>
process/stable-api-nonsense.rst} (89%)
rename Documentation/translations/zh_CN/{stable_kernel_rules.txt =>
process/stable-kernel-rules.rst} (76%)
rename Documentation/translations/zh_CN/{SubmittingDrivers =>
process/submitting-drivers.rst} (86%)
rename Documentation/translations/zh_CN/{SubmittingPatches =>
process/submitting-patches.rst} (93%)
rename Documentation/translations/zh_CN/{volatile-considered-harmful.txt =>
process/volatile-considered-harmful.rst} (81%)
--
2.19.1.856.g8858448bb
[PATCH 01/20] docs/zh_CN: add disclaimer file
This a disclaimer file which will be included in Chinese files as header. To reduce the same common contents copy. Most of contents quoted from Federico Vaga's file: Documentation/translations/it_IT/disclaimer-ita.rst. Thanks a lot! Signed-off-by: Alex Shi Cc: Harry Wei Cc: Jonathan Corbet Cc: Li Zefan Cc: Shawn Guo Cc: Fengguang Wu Cc: Coly Li Cc: Federico Vaga --- Documentation/translations/zh_CN/disclaimer-zh_CN.rst | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 Documentation/translations/zh_CN/disclaimer-zh_CN.rst diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst new file mode 100644 index ..0de5dfb069ca --- /dev/null +++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst @@ -0,0 +1,11 @@ +:orphan: + +.. warning:: + The purpose of this file is to be easier to read and understand for Chinese + speakers and is not intended as a fork. So, if you have any comments or + updates for this file please try to update the original English file first. + +.. note:: + If you find any difference between this document and the original file or a + problem with the translation, please contact the maintainer of this file, + or get help from Alex Shi -- 2.19.1.856.g8858448bb
