Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
On Tue, 17 Jan 2023, Christian Zigotzky wrote:
> >> The reboot issue is still present in the RC2 of kernel 6.2. We still need
> >> the
> >> usbhid.patch. [1]
> >>
> >> Please check the bad commit. [2]
> > Ankit,
> >
> > have you tested with all the devices that you added the quirk for in your
> > original patch?
> >
> > Unless I hear otherwise, I will just drop
> > the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified.
> >
> > Thanks,
> >
> The issue also affects the RC4.
Given the lack of input from Ankit, I have just queued the patch below in
for-6.2/upstream-fixes.
From: Jiri Kosina
Subject: [PATCH] HID: revert CHERRY_MOUSE_000C quirk
This partially reverts commit f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL
quirk
for some mice"), as it turns out to break reboot on some platforms for reason
yet to be understood.
Fixes: f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk for some mice")
Reported-by: Christian Zigotzky
Signed-off-by: Jiri Kosina
---
drivers/hid/hid-ids.h| 1 -
drivers/hid/hid-quirks.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 82713ef3aaa6..c3735848ed5d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -274,7 +274,6 @@
#define USB_DEVICE_ID_CH_AXIS_295 0x001c
#define USB_VENDOR_ID_CHERRY 0x046a
-#define USB_DEVICE_ID_CHERRY_MOUSE_000C0x000c
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
#define USB_DEVICE_ID_CHERRY_CYMOTION_SOLAR0x0027
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 0e9702c7f7d6..be3ad02573de 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -54,7 +54,6 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_YOKE),
HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS),
HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_THROTTLE),
HID_QUIRK_NOGET },
- { HID_USB_DEVICE(USB_VENDOR_ID_CHERRY,
USB_DEVICE_ID_CHERRY_MOUSE_000C), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB),
HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB),
HID_QUIRK_NO_INIT_REPORTS },
--
Jiri Kosina
SUSE Labs
Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
On Fri, 6 Jan 2023, Christian Zigotzky wrote: > Hello, > > The reboot issue is still present in the RC2 of kernel 6.2. We still need the > usbhid.patch. [1] > > Please check the bad commit. [2] Ankit, have you tested with all the devices that you added the quirk for in your original patch? Unless I hear otherwise, I will just drop the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] HID: udraw-ps3: Replace HTTP links with HTTPS ones
On Sat, 18 Jul 2020, Bastien Nocera wrote: > > Rationale: > > Reduces attack surface on kernel devs opening the links for MITM > > as HTTPS traffic is much harder to manipulate. > > > > Deterministic algorithm: > > For each file: > > If not .svg: > > For each line: > > If doesn't contain `\bxmlns\b`: > > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: > > If both the HTTP and HTTPS versions > > return 200 OK and serve the same content: > > Replace HTTP with HTTPS. > > > > Signed-off-by: Alexander A. Klimov > > Looks good! > > Acked-by: Bastien Nocera Applied, thanks. -- Jiri Kosina SUSE Labs
Re: [PATCH] powerpc/sysdev: fix compile errors
On Mon, 18 May 2020, Jiri Kosina wrote:
> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > > implicit-declaration compile errors when building Cache-Sram.
> > >
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > > ‘instantiate_cache_sram’:
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit
> > > declaration
> > > of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
> > > [-Werror=implicit-function-declaration]
> > >cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > >^~~~
> > >bitmap_complement
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
> > > pointer from integer without a cast [-Werror=int-conversion]
> > >cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > > ^
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit
> > > declaration
> > > of function ‘iounmap’; did you mean ‘roundup’?
> > > [-Werror=implicit-function-declaration]
> > >iounmap(cache_sram->base_virt);
> > >^~~
> > >roundup
> > > cc1: all warnings being treated as errors
> > >
> > > Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> > > Signed-off-by: WANG Wenhu
> >
> > Reviewed-by: Christophe Leroy
>
> As this doesn't seem to have been picked up for linux-next yet, I am
> picking it up now.
Only now I've noticed that this is actually a dead code o_O as this file
can't be built by any combination of config options. So I am dropping the
patch again, but why do we keep it in the tree in the first place?
--
Jiri Kosina
SUSE Labs
Re: [PATCH] powerpc/sysdev: fix compile errors
On Mon, 2 Mar 2020, Christophe Leroy wrote:
> > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > implicit-declaration compile errors when building Cache-Sram.
> >
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > ‘instantiate_cache_sram’:
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration
> > of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
> > [-Werror=implicit-function-declaration]
> >cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> >^~~~
> >bitmap_complement
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
> > pointer from integer without a cast [-Werror=int-conversion]
> >cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > ^
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration
> > of function ‘iounmap’; did you mean ‘roundup’?
> > [-Werror=implicit-function-declaration]
> >iounmap(cache_sram->base_virt);
> >^~~
> >roundup
> > cc1: all warnings being treated as errors
> >
> > Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> > Signed-off-by: WANG Wenhu
>
> Reviewed-by: Christophe Leroy
As this doesn't seem to have been picked up for linux-next yet, I am
picking it up now.
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH v2 0/5] cpu/speculation: Add 'mitigations=' cmdline option
On Fri, 12 Apr 2019, Josh Poimboeuf wrote: > v2: > - docs improvements: [Randy, Michael] > - Rename to "mitigations=" [Michael] > - Add cpu_mitigations_off() function wrapper [Michael] > - x86: Simplify logic [Boris] > - powerpc: Fix no_rfi_flush checking bug (use '&&' instead of '||') > - arm64: Rebase onto Jeremy Linton's v7 patches [Will] > - arm64: "kpti command line option" [Steve P] > - arm64: Add nospectre_v2 support > > --- > > Keeping track of the number of mitigations for all the CPU speculation > bugs has become overwhelming for many users. It's getting more and more > complicated to decide which mitigations are needed for a given > architecture. Complicating matters is the fact that each arch tends to > have its own custom way to mitigate the same vulnerability. > > Most users fall into a few basic categories: > > a) they want all mitigations off; > > b) they want all reasonable mitigations on, with SMT enabled even if >it's vulnerable; or > > c) they want all reasonable mitigations on, with SMT disabled if >vulnerable. > > Define a set of curated, arch-independent options, each of which is an > aggregation of existing options: > > - mitigations=off: Disable all mitigations. > > - mitigations=auto: [default] Enable all the default mitigations, but > leave SMT enabled, even if it's vulnerable. > > - mitigations=auto,nosmt: Enable all the default mitigations, disabling > SMT if needed by a mitigation. > > Josh Poimboeuf (5): > cpu/speculation: Add 'mitigations=' cmdline option > x86/speculation: Support 'mitigations=' cmdline option > powerpc/speculation: Support 'mitigations=' cmdline option > s390/speculation: Support 'mitigations=' cmdline option > arm64/speculation: Support 'mitigations=' cmdline option Tested-by: Jiri Kosina (on x86) Reviewed-by: Jiri Kosina Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
On Thu, 4 Apr 2019, Josh Poimboeuf wrote: > Configure powerpc CPU runtime speculation bug mitigations in accordance > with the 'cpu_spec_mitigations=' cmdline options. This affects > Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass. [ ... snip ... ] > - if (!no_nospec) > + if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF) '!no_nospec' is something that I am sure will come back to hunt me in my bad dreams. But that's been there already, and fixing it is out of scope of this patch. Other than that, as discussed previously -- I really like this new global option. Feel free to add Reviewed-by: Jiri Kosina for the whole set. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH 0/4] powerpc/livepatch: reliable stack unwinder fixes
On Wed, 30 Jan 2019, Michael Ellerman wrote: > I'm happy to take it, unless there's some reason you'd rather it go via > the LP tree? As this is more about reliable stack unwinding than live patching per se (which is only a user of that facility), I'd actually slightly prefer if it goes via your tree. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH 0/4] powerpc/livepatch: reliable stack unwinder fixes
On Tue, 22 Jan 2019, Joe Lawrence wrote: > This patchset fixes a false negative report (ie, unreliable) from the > ppc64 reliable stack unwinder, discussed here [1] when it may > inadvertently trip over a stale exception marker left on the stack. > > The first two patches fix this bug. Nicolai's change clears the marker > from the stack when an exception is finished. The next patch modifies > the unwinder to only look for such on stack elements when the ABI > guarantees that they will actually be initialized. > > The final two patches consist of code cleanups that Nicolai and I > spotted during the development of the fixes. > > Testing included re-running the original test scenario (loading a > livepatch module on ppc64le) on a 5.0.0-rc2 kernel as well as a RHEL-7 > backport. I ran internal tests on the RHEL-7 backport and no new test > failures were introduced. I believe that Nicolai has done the same > with respect to the first patch. > > [1] > https://lore.kernel.org/lkml/7f468285-b149-37e2-e782-c9e538b99...@redhat.com/ > > Joe Lawrence (3): > powerpc/livepatch: relax reliable stack tracer checks for first-frame > powerpc/livepatch: small cleanups in save_stack_trace_tsk_reliable() > powerpc/livepatch: return -ERRNO values in > save_stack_trace_tsk_reliable() > > Nicolai Stange (1): > powerpc/64s: Clear on-stack exception marker upon exception return Michael, are you fine with this going through LP tree, or do you plan to take it through yours? Thanks, -- Jiri Kosina SUSE Labs
Re: [git pull] Please pull powerpc.git next branch
On Wed, 20 Jun 2018, Benjamin Herrenschmidt wrote: > > I love the alleged line removal, but there's nothing in that 'merge' > > branch. It points to an ancient powerpc commit from 2016. > > > > And please, signed tags. I know you do them, because you used to send me > > them. > > I didn't send this. It's an ancient (8 years old) email... I have no > idea how it got resent while I was asleep... I got a few mails from 2010 this morning as well. From the headers it looks like Mauro (CCed) re-bounced them for some reason. -- Jiri Kosina SUSE Labs
Re: [PATCH v4 1/2] livepatch: send a fake signal to all blocking tasks
On Wed, 15 Nov 2017, Miroslav Benes wrote: > Live patching consistency model is of LEAVE_PATCHED_SET and > SWITCH_THREAD. This means that all tasks in the system have to be marked > one by one as safe to call a new patched function. Safe means when a > task is not (sleeping) in a set of patched functions. That is, no > patched function is on the task's stack. Another clearly safe place is > the boundary between kernel and userspace. The patching waits for all > tasks to get outside of the patched set or to cross the boundary. The > transition is completed afterwards. > > The problem is that a task can block the transition for quite a long > time, if not forever. It could sleep in a set of patched functions, for > example. Luckily we can force the task to leave the set by sending it a > fake signal, that is a signal with no data in signal pending structures > (no handler, no sign of proper signal delivered). Suspend/freezer use > this to freeze the tasks as well. The task gets TIF_SIGPENDING set and > is woken up (if it has been sleeping in the kernel before) or kicked by > rescheduling IPI (if it was running on other CPU). This causes the task > to go to kernel/userspace boundary where the signal would be handled and > the task would be marked as safe in terms of live patching. > > There are tasks which are not affected by this technique though. The > fake signal is not sent to kthreads. They should be handled differently. > They can be woken up so they leave the patched set and their > TIF_PATCH_PENDING can be cleared thanks to stack checking. > > For the sake of completeness, if the task is in TASK_RUNNING state but > not currently running on some CPU it doesn't get the IPI, but it would > eventually handle the signal anyway. Second, if the task runs in the > kernel (in TASK_RUNNING state) it gets the IPI, but the signal is not > handled on return from the interrupt. It would be handled on return to > the userspace in the future when the fake signal is sent again. Stack > checking deals with these cases in a better way. > > If the task was sleeping in a syscall it would be woken by our fake > signal, it would check if TIF_SIGPENDING is set (by calling > signal_pending() predicate) and return ERESTART* or EINTR. Syscalls with > ERESTART* return values are restarted in case of the fake signal (see > do_signal()). EINTR is propagated back to the userspace program. This > could disturb the program, but... > > * each process dealing with signals should react accordingly to EINTR > return values. > * syscalls returning EINTR happen to be quite common situation in the > system even if no fake signal is sent. > * freezer sends the fake signal and does not deal with EINTR anyhow. > Thus EINTR values are returned when the system is resumed. > > The very safe marking is done in architectures' "entry" on syscall and > interrupt/exception exit paths, and in a stack checking functions of > livepatch. TIF_PATCH_PENDING is cleared and the next > recalc_sigpending() drops TIF_SIGPENDING. In connection with this, also > call klp_update_patch_state() before do_signal(), so that > recalc_sigpending() in dequeue_signal() can clear TIF_PATCH_PENDING > immediately and thus prevent a double call of do_signal(). > > Note that the fake signal is not sent to stopped/traced tasks. Such task > prevents the patching to finish till it continues again (is not traced > anymore). > > Last, sending the fake signal is not automatic. It is done only when > admin requests it by writing 1 to signal sysfs attribute in livepatch > sysfs directory. > > Signed-off-by: Miroslav Benes > Cc: Oleg Nesterov > Cc: Michael Ellerman > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Andy Lutomirski > Cc: linuxppc-dev@lists.ozlabs.org > Cc: x...@kernel.org > --- > Documentation/ABI/testing/sysfs-kernel-livepatch | 12 +++ > Documentation/livepatch/livepatch.txt| 11 +-- > arch/powerpc/kernel/signal.c | 6 ++-- > arch/x86/entry/common.c | 6 ++-- > kernel/livepatch/core.c | 30 + > kernel/livepatch/transition.c| 41 > > kernel/livepatch/transition.h| 1 + > kernel/signal.c | 4 ++- I'd like to be queuing this patchset for the next merge window, so if there are any objections for the out-of-kernel/livepatch/* changes, please speak up now. Thanks. -- Jiri Kosina SUSE Labs
Re: [PATCH v2 2/3] livepatch: send a fake signal to all blocking tasks
On Fri, 11 Aug 2017, Josh Poimboeuf wrote:
> > + read_lock(&tasklist_lock);
> > + for_each_process_thread(g, task) {
> > + if (!klp_patch_pending(task))
> > + continue;
> > +
> > + /*
> > +* There is a small race here. We could see TIF_PATCH_PENDING
> > +* set and decide to wake up a kthread or send a fake signal.
> > +* Meanwhile the task could migrate itself and the action
> > +* would be meaningless. It is not serious though.
> > +*/
> > + if (task->flags & PF_KTHREAD) {
> > + /*
> > +* Wake up a kthread which still has not been migrated.
> > +*/
> > + wake_up_process(task);
> > + } else {
> > + /*
> > +* Send fake signal to all non-kthread tasks which are
> > +* still not migrated.
> > +*/
> > + spin_lock_irq(&task->sighand->siglock);
> > + signal_wake_up(task, 0);
> > + spin_unlock_irq(&task->sighand->siglock);
> > + }
> > + }
> > + read_unlock(&tasklist_lock);
>
> I can't remember if we talked about this before, is it possible to also
> signal/wake the idle tasks?
Scheduler won't select idle task in case there is *anything* else runnable
in any other sched class anyway. And if that is the case, there is no need
for explicit wakeup, as idle task would get scheduled anyway implicitly.
So idle task is a little bit more difficult than that, unfortunately.
--
Jiri Kosina
SUSE Labs
Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel
On Thu, 25 May 2017, Abdul Haleem wrote: > Hi, > > Test : boot > Machine : Power 8 PowerVM LPAR > Kernel version : 4.12.0-rc2-next-20170524 > Toolchain : gcc version 5.2.1 > Config : attached > > next-20170517 was last good version where we did not see the failure. > from next-20170519 to today's next-20170524, we see the problem > everyday. > > Kernels fails to boot on PowerVM LPAR with these errors; > > Freeing unused kernel memory: 4416K > This architecture does not have kernel memory protection. > Loading, please wait... > mount: mounting udev on /dev failed: Device or resource busy > W: devtmpfs not available, falling back to tmpfs for /dev > starting version 222 > Begin: Loading essential drivers ... done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: > Running /scripts/local-top ... done. > chvt: can't open console > Gave up waiting for root device. Common problems: > - Boot args (cat /proc/cmdline) >- Check rootdelay= (did the system wait long enough?) >- Check root= (did the system wait for the right device?) > - Missing modules (cat /proc/modules; ls /dev) > chvt: can't open console > ALERT! /dev/disk/by-uuid/3aee8de3-5b8f-4a89-9e89-108efe213983 does not > exist. Dropping to a shell! Seems like the by-uuid node for your harddrive containing rootfs didn't show up. The EBUSY from mount(/dev) seems like the biggest suspect. These: > hid: module verification failed: signature and/or required key missing - > tainting kernel > hidraw: raw HID events driver (C) Jiri Kosina > usbcore: registered new interface driver usbhid > usbhid: USB HID core driver are for sure unrelated. Please focus on figuring out why mounting /dev doesn't succeed. -- Jiri Kosina SUSE Labs
Re: [PATCH v5 00/15] livepatch: hybrid consistency model
On Mon, 13 Feb 2017, Josh Poimboeuf wrote: > Here's v5 of the consistency model I have ammended the patches with all the received ACKs and applied to 'for-4.12/klp-hybrid-consistency-model' branch of livepatching.git. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v4 00/15] livepatch: hybrid consistency model
On Wed, 1 Feb 2017, Josh Poimboeuf wrote: > If there are no more comments, it would be great to get these patches in > for the 4.11 merge window. Any objections to that? That'd mean that the exposure in -next would be really short, which I'd like to avoid. I'd love to tentatively target 4.12 though (I personally am still far from being done with reviewing the patchset myself, thanks a lot to Peter and Miroslav for doing all the heavy lifting on this front so far). More importantly though, we're still missing quite some Acks from subsystem/arch maintainers. Namely, I'd really appreciate Acks for patches touching sched/idle.c and s390/x86/ppc arch specific bits from the respective maintainers. Peter, Ingo, Heiko, Michael, please? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] powerpc/livepatch: Remove klp_write_module_reloc() stub
On Fri, 16 Dec 2016, Kamalesh Babulal wrote:
> commit 425595a7fc20 ("livepatch: reuse module loader code
> to write relocations") offloads livepatch module relocation
> write to arch specific module loader code.
>
> Remove unused klp_write_module_reloc() function stub.
>
> Signed-off-by: Kamalesh Babulal
> ---
> arch/powerpc/include/asm/livepatch.h | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/livepatch.h
> b/arch/powerpc/include/asm/livepatch.h
> index a402f7f..47a03b9 100644
> --- a/arch/powerpc/include/asm/livepatch.h
> +++ b/arch/powerpc/include/asm/livepatch.h
> @@ -28,13 +28,6 @@ static inline int klp_check_compiler_support(void)
> return 0;
> }
>
> -static inline int klp_write_module_reloc(struct module *mod, unsigned long
> - type, unsigned long loc, unsigned long value)
> -{
> - /* This requires infrastructure changes; we need the loadinfos. */
> - return -ENOSYS;
> -}
> -
> static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> {
> regs->nip = ip;
Applied, thanks.
--
Jiri Kosina
SUSE Labs
RE: livepatch: change to a per-task consistency model
On Tue, 24 May 2016, David Laight wrote: > > > Related, please can we have a flag for the sleep and/or process so that > > > an uninterruptible sleep doesn't trigger the 'hung task' detector > > > > TASK_KILLABLE > > Not sure that does what I want. > It appears to allow some 'kill' actions to wake the process. > I'm sure I've looked at the 'hung task' code since 2007. The trick is the if (t->state == TASK_UNINTERRUPTIBLE) test in check_hung_uninterruptible_tasks(). That makes sure that TASK_KILLABLE tasks (e.g. waiting on NFS I/O, but not limited only to that; feel free to set it whereever you need) are skipped. Please note that TASK_KILLABLE is actually a _mask_ that includes TASK_UNINTERRUPTIBLE as well; therefore the '==' test skips such tasks. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking
On Fri, 20 May 2016, Andy Lutomirski wrote: > I think it would be negligible, at least for interrupts, since > interrupts are already extremely expensive. But I don't love adding > assembly code that makes them even slower. The real thing I dislike > about this approach is that it's not a normal stack frame, so you need > code in the unwinder to unwind through it correctly, which makes me > think that you're not saving much complexity by adding the pushes. I fail to see what is so special about the stack frame; it's in fact pretty normal. It has added semantic value for "those who know", but the others will (pretty much correctly) consider it to be a stackframe from a function call, and be done with it. What am I missing? Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: livepatch: change to a per-task consistency model
On Mon, 23 May 2016, David Laight wrote: > Related, please can we have a flag for the sleep and/or process so that > an uninterruptible sleep doesn't trigger the 'hung task' detector TASK_KILLABLE > and also stops the process counting towards the 'load average'. TASK_NOLOAD -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: livepatch: change to a per-task consistency model
On Wed, 18 May 2016, Josh Poimboeuf wrote: > Yeah, I think this situation -- a task sleeping on an affected function > in uninterruptible state for a long period of time -- would be > exceedingly rare and not something we need to worry about for now. Plus in case task'd be in TASK_UNINTERRUPTIBLE for more than 120s, hung task detector would trigger anyway. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: livepatch: change to a per-task consistency model
On Tue, 17 May 2016, Jessica Yu wrote: > What about tasks sleeping on affected functions in uninterruptible sleep > (possibly indefinitely)? Since all signals are ignored, we wouldn't be > able to patch those tasks in this way, right? Would that be an > unsupported case? I don't think there is any better way out of this situation than documenting that the convergence of patching could in such cases could take quite a lot of time (well, we can pro-actively try to detect this situation before the patching actually start, and warn about the possible consequences). But let's face it, this should be pretty uncommon, because (a) it's not realistic for the wait times to be really indefinite (b) the task is likely to be in TASK_KILLABLE rather than just plain TASK_UNINTERRUPTIBLE. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: klp_task_patch: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model
On Wed, 4 May 2016, Petr Mladek wrote: > > + > > + if (unlikely(klp_patch_pending(current))) > > + klp_patch_task(current); > > } > > Some more ideas from the world of crazy races. I was shaking my head > if this was safe or not. > > The problem might be if the task get rescheduled between the check > for the pending stuff The code in question is running with preemption disabled. > or inside the klp_patch_task() function. We must make sure that this function doesn't go to sleep. It's only used to clear the task_struct flag anyway. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking
On Mon, 2 May 2016, Jiri Kosina wrote:
> > FWIW, I just tried this:
> >
> > static bool is_entry_text(unsigned long addr)
> > {
> > return addr >= (unsigned long)__entry_text_start &&
> > addr < (unsigned long)__entry_text_end;
> > }
> >
> > it works. So the entry code is already annotated reasonably well :)
> >
> > I just hacked it up here:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=stack&id=085eacfe0edfc18768e48340084415dba9a6bd21
> >
> > and it seems to work, at least for page faults. A better
> > implementation would print out the entire contents of pt_regs so that
> > people reading the stack trace will know the registers at the time of
> > the exception, which might be helpful.
>
> Sorry for being dense, but how do you distinguish here between a "real"
> kernel entry, that pushes pt_regs, and any "non-entry" function call that
> passes pt_regs around?
Umm, actually, the more tricky part is the other way around -- how do you
make sure that whenever you are calling out from a code between
__entry_text_start and __entry_text_end, pt_regs will be at the place
you're looking for it? How's that guaranteed?
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking
On Mon, 2 May 2016, Andy Lutomirski wrote:
> FWIW, I just tried this:
>
> static bool is_entry_text(unsigned long addr)
> {
> return addr >= (unsigned long)__entry_text_start &&
> addr < (unsigned long)__entry_text_end;
> }
>
> it works. So the entry code is already annotated reasonably well :)
>
> I just hacked it up here:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=stack&id=085eacfe0edfc18768e48340084415dba9a6bd21
>
> and it seems to work, at least for page faults. A better
> implementation would print out the entire contents of pt_regs so that
> people reading the stack trace will know the registers at the time of
> the exception, which might be helpful.
Sorry for being dense, but how do you distinguish here between a "real"
kernel entry, that pushes pt_regs, and any "non-entry" function call that
passes pt_regs around?
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking
On Fri, 29 Apr 2016, Andy Lutomirski wrote: > > NMI, MCE and interrupts aren't a problem because they have dedicated > > stacks, which are easy to detect. If the tasks' stack is on an > > exception stack or an irq stack, we consider it unreliable. > > Only on x86_64. Well, MCEs are more or less x86-specific as well. But otherwise good point, thanks Andy. So, how does stack layout generally look like in case when NMI is actually running on proper kernel stack? I thought it's guaranteed to contain pt_regs anyway in all cases. Is that not guaranteed to be the case? Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] livepatch: Add some basic LivePatch documentation
On Wed, 27 Apr 2016, Jiri Kosina wrote: > I've incorporated most of the feedback (*) and pushed out to > livepatching.git#for-4.7/livepatching-doc so everybody please send any > followup documentation patches on top of that branch. (*) Balbir, some of your comments were a bit too vague; if you could turn them into actual patch on top of what's currently in git, that'd be helpful -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] livepatch: Add some basic LivePatch documentation
On Tue, 26 Apr 2016, Chris J Arges wrote: [ ... snip ... ] > > + + Kretprobes using the ftrace framework conflict with the patched > > + + Kretprobes using the ftrace framework conflicts with the patched Chris, I've incorporated all your feedback except for this one; are you really sure about it? 'kretprobes' is plural form in this sentence, so what's the rationale for your proposed change? Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] livepatch: Add some basic LivePatch documentation
On Mon, 25 Apr 2016, Petr Mladek wrote: > LivePatch framework deserves some documentation, definitely. > This is an attempt to provide some basic info. I hope that > it will be useful for both LivePatch producers and also > potential developers of the framework itself. > > Signed-off-by: Petr Mladek Good stuff, thanks. I've incorporated most of the feedback (*) and pushed out to livepatching.git#for-4.7/livepatching-doc so everybody please send any followup documentation patches on top of that branch. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] Live patching for powerpc
On Wed, 20 Apr 2016, Balbir Singh wrote: > Thanks, do we have a summary of what the relocation changes look like? This work is queued in livepatching.git#for-4.7/arch-independent-klp-relocations -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] Live patching for powerpc
On Thu, 14 Apr 2016, Michael Ellerman wrote: > Topic branch here: > > > https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=topic/livepatch > > I will merge that before Monday (my time) if I don't hear any objections. I've now pulled this into livepatching.git#for-4.7/livepatching-ppc64 and merged that branch into for-next as well. That branch already contains all the relocation changes queued for 4.7, so as much testing of the merged result as possible on ppc64 would be appreciated. Thanks everybody, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] Live patching for powerpc
On Thu, 14 Apr 2016, Torsten Duwe wrote: > > > > > It's unchanged since the version I posted on March 24, with the > > > > > exception that > > > > > I've dropped the first patch, which was a testing-only patch. > > Confirmed. And it still works on top of 4.6-rc3, even with the > additional testing. Thanks a lot for testing. The imporant part here is testing on top of livepatching.git#for-4.7/arch-independent-klp-relocations as well. I am pretty sure there will be adjustments needed for the merge, as we'll have to figure out which parts of ELF can't be thrown away and need to be preserved in order for the relocation entry to be successfully constructed. Michael, I think this is an additional reason why the whole final pile will have to go through livepatching.git, as the merge with what we have in for-4.7/arch-independent-klp-relocations might not be completely trivial. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] Live patching for powerpc
On Wed, 13 Apr 2016, Miroslav Benes wrote: > > This series adds live patching support for powerpc (ppc64le only ATM). > > > > It's unchanged since the version I posted on March 24, with the exception > > that > > I've dropped the first patch, which was a testing-only patch. > > > > If there's no further comments I'll put this in a topic branch in the next > > day > > or two and Jiri & I will both merge that into next. > > Hi, > > I'll definitely give it a proper look today or tomorrow, but there is one > thing that needs to be solved. The patch set from Jessica reworking > relocations for live patching is now merged in our for-next branch. This > means that we need to find out if there is something in struct > mod_arch_specific for powerpc which needs to be preserved and do it. Michael, if the plan is still the original one, i.e. you push it to your branch, and I merge it to livepatching (and resolve any dependencies on the relocations code during the merge) and push it to Linus from livepatching.git, then there shouldn't be anything do to on your side. Alternatively, you can rebase on top of livepatching.git#for-next, and I'll take it directly. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] ftrace: Make ftrace_location_range() global
On Thu, 24 Mar 2016, Steven Rostedt wrote: > > In order to support live patching on powerpc we would like to call > > ftrace_location_range(), so make it global. > > Do you want me to try to get this into this merge window? I don't think that's necessary. The dependency (rest of livepatching bits for ppc64le) will not go in before 4.7 merge window anyway. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,1/8] powerpc: Create a helper for getting the kernel toc value
On Mon, 14 Mar 2016, Michael Ellerman wrote: > > Move the logic to work out the kernel toc pointer into a header. This is > > a good cleanup, and also means we can use it elsewhere in future. > > > > Reviewed-by: Kamalesh Babulal > > Reviewed-by: Torsten Duwe > > Signed-off-by: Michael Ellerman > > Tested-by: Kamalesh Babulal > > Series applied to powerpc next. > > https://git.kernel.org/powerpc/c/a5cab83cd3d2d75d3893276cb5 Thanks Michael; this is an excellent basis for ppc live patching, but FYI I am not merging that one to my tree just yet. The solution (*) for functions with non-trivial argument list is not there yet, and it's my requirement for this to be taken care of in a way that's not prone to easily-done human errors on the patch-producer side. (*) both "making it work" or "making it so broken that it's guaranteed that noone would ever produce a patch that brings the kernel down" is okay, but I really don't feel that just documenting the limitation is sufficient and safe in this case; kudos to Torsten here for idenfitfying the problem before it actually became The Problem Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame
On Thu, 10 Mar 2016, Petr Mladek wrote: > BTW: How is this solved in kretprobes? Or is it easier there? Is that really a problem? With kretprobes you're never performing the module->core->module transition in "one" redirection, right? The 'kretprobe_trampoline' is a global symbol, and hence everybody is generating 'global call' for it, and that's pretty much it. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] livepatch: Add some basic LivePatch documentation
On Wed, 9 Mar 2016, Petr Mladek wrote: > LivePatch framework deserves some documentation, definitely. > This is an attempt to provide some basic info. I hope that > it will be useful for both LivePatch producers and also > potential developers of the framework itself. Thanks for starting the efforts; this is really needed if we want the infrastructure to be used also by someone else than its developers :) [ ... snip ... ] > +7. Limitations > +== Miroslav Benes, who is working on creating the actual patches we are shipping for our kernels, should already have a decent cheat-sheet regarding things that the patch author should be extra careful when creating a patch (inlining and other gcc optimizations such as isra, functions that use switch_to(), percpu, ...). I am not really sure whether these should go to limitations, or maybe they'd better be placed into a separate chapter, but I'd really like to see it included. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc
On Wed, 9 Mar 2016, Torsten Duwe wrote: > > find a solution that would work transparently. I mean that adding > > an extra hacks into selected functions in the patch might be quite > > error prone and problems hard to debug. I think that we all want this > > but I wanted to be sure :-) > > Full ACK. Again, the TOC restore needs to go _after_ the replacement function, > and the klp_return_helper works as transparently as possible, so this > was my first choice. Arguments on the stack? I thought we'll deal with them > once we get there (e.g. _really_ need to patch a varargs function or one > with a silly signature). Well, the problem is, once such need arises, it's too late already. You need to be able to patch the kernels which are already out there, running on machines potentially for ages once all of a sudden there is a CVE for >8args / varargs function. At that time, only starting to put support in the kernel for that is waaay to late :) Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to merge? (was Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc)
On Mon, 7 Mar 2016, Michael Ellerman wrote: > > This aligns with my usual workflow, so that'd be my preferred way of doing > > things; i.e. you put all the ftrace changes into a separate topic branch, > > and then > > > > - you pull that branch into powerpc#next > > - I pull that branch into livepatching tree > > - I apply the ppc livepatching support on top of that > > - I send a pull request to Linus only after powerpc#next gets merged to > > Linus' tree > > > > Sounds good? > > Yep, here it is: > > > https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=topic/mprofile-kernel > > aka: > > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > topic/mprofile-kernel Excellent, thanks. > I haven't merged it into my next yet, but I will tomorrow unless you tell me > there's something wrong with it. There is one remaining issue which I think would be really nice to have(TM), and that's Steven's Ack for the whole thing :) For the livepatching part, I don't think we are quite there yet (so maybe it'll miss the upcoming merge window anyway). My primary worry there is what Torsten pointed out, i.e. functions with either varargs or more than 8 args needing special care. Also, I'd like to have this positively reviewed by at least one more livepatching maintainer (I am currently looking into it myself, but my understanding of powerpc arch is rather low, so the more eyes, the better). Thanks! -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to merge? (was Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc)
On Fri, 4 Mar 2016, Michael Ellerman wrote: > Obviously it depends heavily on the content of my series, which will go into > powerpc#next, so it would make sense if this went there too. > > I don't see any changes in linux-next for livepatch, so merging it via powerpc > would probably work fine and not cause any conflicts, unless there's some > livepatch changes pending for 4.6 that aren't in linux-next yet? > > The other option is that I put my ftrace changes and this in a topic branch > (based on v4.5-rc3), and then that can be merged into both powerpc#next and > the > livepatch tree. This aligns with my usual workflow, so that'd be my preferred way of doing things; i.e. you put all the ftrace changes into a separate topic branch, and then - you pull that branch into powerpc#next - I pull that branch into livepatching tree - I apply the ppc livepatching support on top of that - I send a pull request to Linus only after powerpc#next gets merged to Linus' tree Sounds good? > Also regardless of who takes it an Ack from Steve for the ftrace changes > would be good. Absolutely. Thanks! -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables
On Mon, 15 Feb 2016, Michael Ellerman wrote:
> > > > +echo "int func() { return 0; }" | \
> > > > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > > > +sed -n -e '/func:/,/bl _mcount/p' | grep -q TOC
> > > > +
> > > > +leaf_toc_result=$?
> > >
> > > leaf_toc_result failed for me with gcc 5. I'll try and grab gcc-6
> > > and give the patches a spin
> >
> > Don't bother. _All_ gccs are broken in that respect currently.
>
> I'm not sure where we got our wires crossed on this one, but this is not a gcc
> bug. In fact it's a feature :)
>
> There is explicit code in gcc to check whether the TOC setup is needed and
> only
> emit it when it's required. One case where it's *not* required is when the
> function does not TOC accesses. (See rs6000_global_entry_point_needed_p()).
As gcc actually implements a '-mprofile-kernel' option, it's pretty much
aware of the fact that the inserted space will be used by the kernel for
inserting a call (as that's the sole point of the whole thing).
Therefore it must not consider any traceable function to be leaf (even
though it might "look" leaf from the source code); if it does, then the
mprofile-kernel option is useless.
So I actually would dare to call it a bug.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/9] ppc64 (le): prepare for -mprofile-kernel
On Thu, 4 Feb 2016, AKASHI Takahiro wrote: > On arm/arm64, link register must be saved before any function call. So anyhow > we will have to add something, 3 instructions at the minimum, like: >save lr >branch _mcount >restore lr > >... > >... This means that we have at least two architectures that need one instruction before the mcount/mfentry call, and the rest of the prologue to follow afterwards. On x86, we don't need any "pre-prologue". Persumably the corresponding opcodes have different sizes. This nicely demonstrates my point -- if this one-gcc-option-to-rule-them-all would exist, it needs to be generic enough to describe these kinds of constraints (who knows what other restrictions will pop up when exploring other, more exotic, architectures later). Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/9] ppc64 (le): prepare for -mprofile-kernel
On Wed, 3 Feb 2016, AKASHI Takahiro wrote: > > The gcc switch -mprofile-kernel, available for ppc64 on gcc > 4.8.5, > > allows to call _mcount very early in the function, which low-level > > ASM code and code patching functions need to consider. > > Especially the link register and the parameter registers are still > > alive and not yet saved into a new stack frame. > > I'm thinking of implementing live patch support *for arm64*, and as part of > those efforts, we are proposing[1] a new *generic* gcc option, -fprolog-add=N. > This option will insert N nop instructions at the beginning of each function. > So we have to initialize those codes at the boot time to later utilize > them for FTRACE_WITH_REGS. Other than that, it will work similarly > with -mfentry on x86 (and -mprofile-kernel?). > > I'm totally unfamiliar with ppc architecture, but just wondering > whether this option will also be useful for other architectures. The interesting part of the story with ppc64 is that you indeed want to create the callsite before the *most* of the prologue, but not really :) The part of the prologue where TOC pointer is saved needs to happen before the fentry/profiling call. I don't think this will be an issue on ARM64, but it definitely is something that should be taken into account in case the gcc option is meant to be really generic. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 8/9] Implement kernel live patching for ppc64le (ABIv2)
On Tue, 2 Feb 2016, Petr Mladek wrote: > Note that TOC is not set only when the problematic functions are > compiled with --mprofile-kernel. I still see the TOC stuff when > compiling only with -pg. I don't see how this wouldn't be a gcc bug. No matter whether it's plain profiling call (-pg) or kernel profiling call (-mprofile-kernel), gcc must always assume that global function (that will typically have just one instance for the whole address space) will be called. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 0/9] ftrace with regs + live patching for ppc64 LE (ABI v2)
On Thu, 21 Jan 2016, Torsten Duwe wrote: > > mcount call sites looks normal on first sight... > > Not quite. > LR is not saved on the stack before the call. > Argh! > > Petr, this looks like 12 bytes offset for gcc-6. > I think I can work around the rest. Are we sure that gcc is doing the right thing here? I am far from claiming understanding of ppc64 ABI, but from what Vojtech told me I understood that saving link register is necessary for (at least) graph tracer to work properly. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 0/9] ftrace with regs + live patching for ppc64 LE (ABI v2)
On Wed, 20 Jan 2016, Michael Ellerman wrote: > For me the series doesn't even boot, even with livepatching disabled. Could you please post config and dmesg from that non-booting kernel? Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/9] ppc64le FTRACE_WITH_REGS implementation
On Tue, 5 Jan 2016, Torsten Duwe wrote: > > I (still) haven't had a chance to have a good look at it, but I won't this > > week > > anyway. So post v5 and hopefully I can review that and it will be perfect :) > > The perfect v5 is there now, for 4 weeks minus the holiday season, and > no further problems arose. Independently verified by Petr Mladek -- > don't forget his high-level fix. Hi everybody, so what are the current plans with this one, please? Is this going through ppc tree, ftrace tree, or does it have issues that need to be worked on before merging? Thanks! -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI
On Fri, 27 Nov 2015, Petr Mladek wrote:
> MN10300 has its own implementation for entering and exiting NMI
> handlers. It does not call nmi_enter() and nmi_exit(). Please, find
> below an updated patch that adds printk_nmi_enter() and
> printk_nmi_exit() to the custom entry points. Then we could add HAVE_NMI
> to arch/mn10300/Kconfig and avoid the above warning.
Hmm, so what exactly would go wrong if MN10300 (whatever that architecture
is) would call nmi_enter() and nmi_exit() at the places where it's
starting and finishing NMI handler?
From a cursory look, it seems like most (if not all) of the things called
from nmi_{enter,exit}() would be nops there anyway.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1)
On Tue, 19 May 2015, Michael Ellerman wrote: > > ftrace already handles recursion protection by itself (depending on the > > per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag). > > OK, so I wonder why that's not working for us? The situation when traced function recurses to itself is different from the situation when tracing core infrastrcuture would recurse to itself while performing tracing. > > It's however not really well-defined what to do when recursion would > > happen. Therefore __notrace__ annotation, that just completely avoid such > > situation by making tracing impossible, looks like saner general solution > > to me. > > I disagree. Correctly annotating all functions that might be called ever and > for all time is a maintenance nightmare and is never going to work in the long > term. All the functions called by ftrace must be marked as notrace, there is no way out of it. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1)
yOn Sat, 16 May 2015, Torsten Duwe wrote: > > > There's got to be a better solution than this. > > > > Can you think of a better approach? > > Maybe a per thread variable to lock out a recursion into tracing? > Thanks for your doubt. ftrace already handles recursion protection by itself (depending on the per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag). It's however not really well-defined what to do when recursion would happen. Therefore __notrace__ annotation, that just completely avoid such situation by making tracing impossible, looks like saner general solution to me. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fix personality handling in ppc64_personality()
On Thu, 6 Sep 2012, Benjamin Herrenschmidt wrote: > > actually commit 7256a5d2da56 seems to contain the correct PER_LINUX > > handling, so seems like you picked the right one :) > > > > Odd, they looked different around the use of PER_MASK when I looked but The original patch had personality &= ~PER_LINUX | PER_LINUX32; Which is bogus, exactly because ~PER_LINUX is -1. I then used personality = (personality & ~PER_MASK) | PER_LINUX32; which is correct and perhaps a little bit more descriptive, and that is what you have merged, so all is fine. > I was tired & jet lagged, so I might have just had a brain fail... Probably just missed that the first patch used PER_LINUX and the second one PER_MASK, or whatever. Anyway, thanks. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fix personality handling in ppc64_personality()
On Wed, 5 Sep 2012, Benjamin Herrenschmidt wrote: > > Directly comparing current->personality against PER_LINUX32 doesn't work > > in cases when any of the personality flags stored in the top three bytes > > are used. > > > > Directly forcefully setting personality to PER_LINUX32 or PER_LINUX > > discards any flags stored in the top three bytes > > > > Use personality() macro to compare only PER_MASK bytes and make sure that > > we are setting only the bits that should be set, instead of > > overwriting the whole value. > > > > Signed-off-by: Jiri Kosina > > --- > > > > changed since v1: fix the bit ops to reflect the fact that PER_LINUX is > > actually 0 > > Had already merged v1 (oops.. didn't spot the issue with PER_LINUX being > 0). Can you send an incremental fixup ? Hi Benjamin, actually commit 7256a5d2da56 seems to contain the correct PER_LINUX handling, so seems like you picked the right one :) Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [RESEND] powerpc: fix personality handling in ppc64_personality()
Directly comparing current->personality against PER_LINUX32 doesn't work
in cases when any of the personality flags stored in the top three bytes
are used.
Directly forcefully setting personality to PER_LINUX32 or PER_LINUX
discards any flags stored in the top three bytes
Use personality() macro to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of overwriting
the whole value.
Signed-off-by: Jiri Kosina
---
Resned of patch sent on Thu, 2 Aug 2012 09:10:03 +0200 (CEST)
arch/powerpc/kernel/syscalls.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index f2496f2..dc1558e 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality)
long ret;
if (personality(current->personality) == PER_LINUX32
- && personality == PER_LINUX)
- personality = PER_LINUX32;
+ && personality(personality) == PER_LINUX)
+ personality = (personality & ~PER_MASK) | PER_LINUX32;
ret = sys_personality(personality);
- if (ret == PER_LINUX32)
- ret = PER_LINUX;
+ if (personality(ret) == PER_LINUX32)
+ ret = (ret & ~PER_MASK) | PER_LINUX;
return ret;
}
#endif
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc: fix personality handling in ppc64_personality()
Directly comparing current->personality against PER_LINUX32 doesn't work in cases when any of the personality flags stored in the top three bytes are used. Directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes Use personality() macro to compare only PER_MASK bytes and make sure that we are setting only the bits that should be set, instead of overwriting the whole value. Signed-off-by: Jiri Kosina --- changed since v1: fix the bit ops to reflect the fact that PER_LINUX is actually 0 arch/powerpc/kernel/syscalls.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c index f2496f2..dc1558e 100644 --- a/arch/powerpc/kernel/syscalls.c +++ b/arch/powerpc/kernel/syscalls.c @@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality) long ret; if (personality(current->personality) == PER_LINUX32 - && personality == PER_LINUX) - personality = PER_LINUX32; + && personality(personality) == PER_LINUX) + personality |= PER_LINUX32; ret = sys_personality(personality); - if (ret == PER_LINUX32) - ret = PER_LINUX; + if (personality(ret) == PER_LINUX32) + ret &= ~PER_LINUX32; return ret; } #endif -- 1.7.3.1 -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix personality handling in ppc64_personality()
Directly comparing current->personality against PER_LINUX32 doesn't work
in cases when any of the personality flags stored in the top three bytes
are used.
Directly forcefully setting personality to PER_LINUX32 or PER_LINUX
discards any flags stored in the top three bytes
Use personality() macro to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina
---
Found accidentally. Untested, I don't have the hardware.
arch/powerpc/kernel/syscalls.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index f2496f2..4dcc7c6 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality)
long ret;
if (personality(current->personality) == PER_LINUX32
- && personality == PER_LINUX)
- personality = PER_LINUX32;
+ && personality(personality) == PER_LINUX)
+ personality &= ~PER_LINUX | PER_LINUX32;
ret = sys_personality(personality);
- if (ret == PER_LINUX32)
- ret = PER_LINUX;
+ if (personality(ret) == PER_LINUX32)
+ ret &= ~PER_LINUX32 | PER_LINUX;
return ret;
}
#endif
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the trivial tree with the powerpc tree
On Fri, 16 Mar 2012, Stephen Rothwell wrote:
> Today's linux-next merge of the trivial tree got a conflict in
> drivers/char/viotape.c between commit ba7a4822b48f ("powerpc: Remove some
> of the legacy iSeries specific device drivers") from the powerpc tree and
> commit a7ccf3775219 ("char: Fix typo in viotape.c") from the trivial tree.
Dropped a7ccf3775219 in my tree, thanks for report Stephen.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3]arch:powerpc:sysdev:mpic.c Remove extra semicolon.
On Thu, 15 Dec 2011, Justin P. Mattock wrote: > what would be the status of these? should I resend/rebase to the current > etc?.. Check linux-next, it's already there. > > On 11/21/2011 08:43 AM, Justin P. Mattock wrote: > > From: "Justin P. Mattock" > > > > The patch below removes an extra semicolon. > > > > Signed-off-by: Justin P. Mattock > > CC: linuxppc-dev@lists.ozlabs.org > > CC: Paul Mackerras > > --- > > arch/powerpc/sysdev/mpic.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c > > index 8c7e852..b3fa3d7 100644 > > --- a/arch/powerpc/sysdev/mpic.c > > +++ b/arch/powerpc/sysdev/mpic.c > > @@ -901,7 +901,7 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int > > flow_type) > > if (vold != vnew) > > mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew); > > > > - return IRQ_SET_MASK_OK_NOCOPY;; > > + return IRQ_SET_MASK_OK_NOCOPY; > > } > > > > void mpic_set_vector(unsigned int virq, unsigned int vector) > -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next bad Kconfig for drivers/hid
On Mon, 12 Dec 2011, Tony Breeds wrote: > On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote: > > On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote: > > > > > > Hm. How about making it "depends on HID && POWER_SUPPLY"? I think that > > > would needlessly disable it if HID is also modular, but I'm not sure how > > > to fix that. "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"? > > That would work, but I think technically I think you could end up with > HID=m and POWER_SUPPLY=m which would still allow HID_BATTERY_STRENGTH=y > which is the same problem. > > I don't know what kind of .config contortions you'd need to do to get > there. > > > How about making it 'default POWER_SUPPLY' instead? > > By itself that wont help as POWER_SUPPLY=m statisfies. > > So it looks like we have Jeremy's: > HID && POWER_SUPPLY && HID == POWER_SUPPLY Tony, have you actually tested this one to work in the configuration you have been seeing it to fail? I don't seem to be able to find any use of '==' in other Kconfig files (and never used it myself), so I'd like to have confirmation that it actually works and fixes the problem before I apply it :) Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next bad Kconfig for drivers/hid
On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote: > > Commit 4f5ca836bef3 (HID: hid-input: add support for HID devices > > reporting Battery Strength) went into linux-next on Dec 1st since then a > > ppc6xx_defconfig has been failing with: > > > > --- > > drivers/built-in.o: In function `hidinput_cleanup_battery': > > /scratch/tony/working/drivers/hid/hid-input.c:351: undefined reference to > > `power_supply_unregister' > > drivers/built-in.o: In function `hidinput_setup_battery': > > /scratch/tony/working/drivers/hid/hid-input.c:338: undefined reference to > > `power_supply_register' > > make[1]: *** [.tmp_vmlinux1] Error 1 > > --- > > > > http://kisskb.ellerman.id.au/kisskb/buildresult/5012563/ > > vs > > http://kisskb.ellerman.id.au/kisskb/buildresult/5017366/ > > > > The defconfig in question doens't mention either option > > (CONFIG_POWER_SUPPLY or CONFIG_HID_BATTERY_STRENGTH) and kbuild is > > genertaing > > CONFIG_HID_BATTERY_STRENGTH=y > > CONFIG_POWER_SUPPLY=m > > which clearly isn't going to work. > > > > The following change to HID_BATTERY_STRENGTH Kconfig "works" but seems a > > little gross. > > > > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig > > index 5ed64f6..d2a94e6 100644 > > --- a/drivers/hid/Kconfig > > +++ b/drivers/hid/Kconfig > > @@ -33,7 +33,7 @@ config HID > > > > config HID_BATTERY_STRENGTH > > bool > > - depends on POWER_SUPPLY > > + depends on POWER_SUPPLY=y > > default y > > > > config HIDRAW > > > > Any chance we can get a fix into linux-next? > > Hm. How about making it "depends on HID && POWER_SUPPLY"? I think that > would needlessly disable it if HID is also modular, but I'm not sure how > to fix that. "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"? How about making it 'default POWER_SUPPLY' instead? I somehow feel that we'd rather avoid too much 'default y's. Thanks, -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5]arch:powerpc:platforms:85xx:mpc85xx_mds.c Typo change singal to signal
On Thu, 30 Dec 2010, Justin P. Mattock wrote: > The patches below fixes a typo "singal" to "signal". Please let me > know if anything needs to be changed. > > Signed-off-by: Justin P. Mattock > > --- > arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c > b/arch/powerpc/platforms/85xx/mpc85xx_mds.c > index aa34cac..747d1ee 100644 > --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c > +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c > @@ -309,7 +309,7 @@ static void __init mpc85xx_mds_qe_init(void) > /* P1021 has pins muxed for QE and other functions. To >* enable QE UEC mode, we need to set bit QE0 for UCC1 >* in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9 > - * and QE12 for QE MII management singals in PMUXCR > + * and QE12 for QE MII management signals in PMUXCR > * register. >*/ Applied. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 RESEND] powerpc: remove cast from void*
On Mon, 27 Sep 2010, matt mooney wrote:
> Unnecessary cast from void* in assignment.
>
> Signed-off-by: matt mooney
> ---
> arch/powerpc/platforms/pseries/hvCall_inst.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c
> b/arch/powerpc/platforms/pseries/hvCall_inst.c
> index e19ff02..f106662 100644
> --- a/arch/powerpc/platforms/pseries/hvCall_inst.c
> +++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
> @@ -55,7 +55,7 @@ static void hc_stop(struct seq_file *m, void *p)
> static int hc_show(struct seq_file *m, void *p)
> {
> unsigned long h_num = (unsigned long)p;
> - struct hcall_stats *hs = (struct hcall_stats *)m->private;
> + struct hcall_stats *hs = m->private;
>
> if (hs[h_num].num_calls) {
> if (cpu_has_feature(CPU_FTR_PURR))
This doesn't seem to be present in 37-rc1, so I am taking it to trivial
queue. If this has been already merged to another tree, let me know.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Failure with the 2.6.34-rc1 kernel
On Tue, 16 Mar 2010, Rupjyoti Sarmah wrote: > -Original Message- > From: Jiri Kosina [mailto:jkos...@suse.cz] > Sent: Tuesday, March 16, 2010 9:18 PM > To: Rupjyoti Sarmah > Cc: linux-ker...@vger.kernel.org > Subject: Re: Failure with the 2.6.34-rc1 kernel > > On Tue, 16 Mar 2010, Rupjyoti Sarmah wrote: > > > We are seeing issues in booting some of our boards with this new > kernel. > > Kernel version upto 2.6.33 works fine on the boards like Canyonlands, > > Katmai, Glacier etc. > > These boards are not booting with kernel later than 2.6.33. Please let > > me know how about fixing these issues ? > > You'd need to provide at least dmesg from the working and non-working > cases. > > Also git-bisect between 2.6.33 and 2.6.34-rc1 might help you identify > the > commit that broke your hardware. > It has been failing from this commit. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > t;h=ef1a8de8ea004a689b2aa9f5cefcba2b1a0262f2 . > > Also, the u-boot restarts the board very quickly. It does not go to the > kernel prompt at all. > That is a merge commit. There must be actuall non-merge commit that introduced the change. If you are sure that this particular commit brought in the change that broke your system, you can do git bisect between 00ebfe58b002f0ff387f60c7cd23bc2b274fce1a and ef1a8de8ea004a689b2aa9f5cefcba2b1a0262f2 to see which of the 88 commits merged as part of ef1a8de8ea004a689b2aa9f5cefcba2b1a0262f2 is the actual culprit. Also adding linuxpcc-dev@ to CC. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] Some typo fixing
On Mon, 15 Mar 2010, Randy Dunlap wrote: > > I have fixed some typos. > > Acked-by: Randy Dunlap > > Jiri, can you merge these, please, unless someone objects (?). Yes, I will take it, thanks. A couple comments though: - [important!] Thomas, it's not necessary to CC zillions of people on such patches. Just submit them to triv...@kernel.org (and eventually CC lkml), and that's it. I believe many people might get annoyed by this. - I will not be applying the drivers/staging hunks. Staging patches are moving target, the code is changing quickly (including complete drops/rewrites) so we'll likely be getting conflicts there. I will reroute them to Greg. - I will fold all the patches into one. We don't need one commit per one specific typo. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] trivial: fix typo s/leve/level/ in powerpc arch
On Sun, 17 Jan 2010, Thadeu Lima de Souza Cascardo wrote: > Signed-off-by: Thadeu Lima de Souza Cascardo > --- > arch/powerpc/mm/tlb_low_64e.S |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S > index f288279..8b04c54 100644 > --- a/arch/powerpc/mm/tlb_low_64e.S > +++ b/arch/powerpc/mm/tlb_low_64e.S > @@ -1,5 +1,5 @@ > /* > - * Low leve TLB miss handlers for Book3E > + * Low level TLB miss handlers for Book3E > * > * Copyright (C) 2008-2009 > * Ben. Herrenschmidt (b...@kernel.crashing.org), IBM Corp. Applied to trivial queue, thanks. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix spelling in comments and documentation
On Wed, 6 Jan 2010, Andrew Morton wrote: > > Replace platfrom -> platform. > > > > This is a frequent spelling bug. > > I have a "no spelling fixes unless they're in documentation or printks" > policy ;) > > triv...@kernel.org would be a suitable recipient for this patch. Yup, I am usually applying all the comment typo fixes, as it makes the source more grepping-friendly. Applied, thanks Stefan. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] char/hvc: adding __init macro to char/hvc_vio.c
On Thu, 17 Sep 2009, Peter Huewe wrote: > > Please have a look at the small patch and either pull it through > > your tree, or please ack' it so Jiri can pull it through the trivial tree. > > > > linux version 2.6.31-rc6 - linus git tree, Do 20. Aug 22:26:06 CEST 2009 > > > > Signed-off-by: Peter Huewe > > Hi Jiri, > this one got merged by Benjamin, so you can drop it from your queue :) > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=948c28fe3001f2c9d852dff2a0b2c69fe7cec91b Dropped, thanks for letting me know. -- Jiri Kosina SUSE Labs, Novell Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Trivial spelling fix in ppc code comments
On Tue, 12 May 2009, Sankar P wrote: > Fixes a trivial spelling error in powerpc code comments. > > Signed-off-by: Sankar P Applied to trivial tree, thanks. -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
