Re: [PATCH] pcmcia: ds: Remove if with always false condition

Am Mon, Mar 01, 2021 at 06:38:47PM +0100 schrieb Uwe Kleine-König: > pcmcia_device_remove() is only ever called by the driver core with > dev->driver pointing to a valid driver. (And even if dev->driver was > NULL, p_drv wouldn't be NULL as p_drv is assigned as follows: > > p_drv =

Re: [PATCH 0/6] Rid W=1 warnings from PCMCIA

Am Fri, Mar 12, 2021 at 11:02:33AM + schrieb Lee Jones: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Lee Jones (6): > pcmcia: rsrc_nonstatic: Demote kernel-doc abuses >

[GIT PULL] pcmcia updates for v5.12

Linus, A lone PCMCIA change since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) is available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next for you to fetch changes up to

Re: [PATCH] pcmcia: Switch to using the new API kobj_to_dev()

Am Tue, Feb 23, 2021 at 05:26:50PM +0800 schrieb Yang Li: > fixed the following coccicheck: > ./drivers/pcmcia/cistpl.c:1584:53-54: WARNING opportunity for > kobj_to_dev() > > Reported-by: Abaci Robot > Signed-off-by: Yang Li Sorry, an equivalent patch is already in pcmcia-next and about to be

Re: [PATCH] cpufreq: Remove CPUFREQ_STICKY flag

Viresh, Am Mon, Feb 01, 2021 at 01:35:51PM +0530 schrieb Viresh Kumar: > The removal of such a driver is avoided if the driver carries the > CPUFREQ_STICKY flag. This was added way back [1] in 2004 and perhaps no > one should ever need it now. A lot of driver do set this flag, probably > because

Re: [PATCH 1/2] docs: Make syscalls' helpers naming consistent

y()`, and so are all the helpers declared bellow it. Change the > documentation to reflect this. > > Cc: Dominik Brodowski > Fixes: 819671ff849b ("syscalls: define and explain goal to not call syscalls > in the kernel") > Signed-off-by: André Almeida Reviewed-by: Dominik Brodowski Thanks, Dominik

Re: [PATCH] pcmcia: Switch to using the new API kobj_to_dev()

Am Mon, Jan 04, 2021 at 09:59:30AM +0800 schrieb Tian Tao: > fixed the following coccicheck: > drivers/pcmcia/cistpl.c:1557:54-55: WARNING opportunity for kobj_to_dev() > drivers/pcmcia/cistpl.c:1584:53-54: WARNING opportunity for kobj_to_dev() > > Signed-off-by: Tian Tao Applied to

[GIT PULL] pcmcia updates for v5.11

Linus, The following changes since commit b3298500b23f0b53a8d81e0d5ad98a29db71f4f0: Merge tag 'for-5.10/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm (2020-12-04 13:28:39 -0800) are available in the Git repository at:

Re: [PATCH] init: fix msleep() is not accurate

Am Fri, Dec 11, 2020 at 11:24:12AM +0800 schrieb Yejune Deng: > See Documentation/timers/timers-howto.rst, msleep() is not > for (1ms - 20ms),use usleep_range() instead. While technically correct, this branch is only taken if the "rootwait" kernel parameter is passed -- and as the kernel is

Re: [PATCH] pcmcia/electra_cf: Fix some return values in 'electra_cf_probe()' in case of error

Am Wed, Jun 17, 2020 at 09:53:26PM +0200 schrieb Christophe JAILLET: > 'status' is known to be 0 at this point. It must be set to a meaningful > value in order to return an error code if one of the 'of_get_property()' > call fails. > > Return -EINVAL in such a case. > > Fixes:

Re: [PATCH REPOST] pcmcia: Remove NEC VRC4173 CARDU

Am Fri, Dec 04, 2020 at 08:20:09PM +0100 schrieb Sebastian Andrzej Siewior: > On 2020-11-19 18:06:24 [+0100], To linux-kernel@vger.kernel.org wrote: > > On 2020-11-13 22:34:08 [+0100], To linux-kernel@vger.kernel.org wrote: > > > This driver is the very definition of bitrotting: > > > - Introduced

Re: [PATCH] pcmcia: db1xxx_ss: remove unneeded semicolon

Am Thu, Sep 10, 2020 at 10:05:24PM +0800 schrieb Jason Yan: > Eliminate the following coccicheck warning: > > drivers/pcmcia/db1xxx_ss.c:455:2-3: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Jason Yan Applied to pcmcia-next. Thanks, Dominik

Re: [PATCH 1/2] pcmcia: at91_cf: move definitions locally

Am Tue, Nov 24, 2020 at 12:07:30PM +0100 schrieb Alexandre Belloni: > On Wed, 30 Sep 2020 20:48:02 +0200, Alexandre Belloni wrote: > > struct at91_cf_data is only used in the driver since all the platforms moved > > to device tree, move its definition locally. > > I've now applied those patches

Re: [PATCH] drivers/pcmcia: Fix error return code in electra_cf_probe()

Am Tue, Nov 24, 2020 at 03:00:40PM +0800 schrieb Wei Li: > When it fails to call of_get_property(), it just jumps to 'fail1', > while the 'status' which will be returned is not updated. > > Fixes: 2b571a066a2f ("pcmcia: CompactFlash driver for PA Semi Electra boards") > Signed-off-by: Wei Li

Re: [PATCH] pcmcia: omap: Fix error return code in omap_cf_probe()

Am Wed, Nov 25, 2020 at 08:50:57PM +0800 schrieb Wang ShaoBo: > Fix to return proper error code instaed of 0 in omap_cf_probe(), as done > elsewhere in this function. > > Signed-off-by: Wang ShaoBo Applied to pcmcia-next. Thanks, Dominik

Re: [PATCH] pcmcia: Remove NEC VRC4173 CARDU

Am Wed, Sep 16, 2020 at 10:16:29AM +0200 schrieb Sebastian Andrzej Siewior: > This driver is the very definition of bitrotting: > - Introduced in commit > 79a140932c776 ("[PATCH] mips: vR41xx updates") > which is 2.6.11-rc3. > > - Provides ->register_callback which was removed in commit >

Re: [PATCH 1/3] dma-mapping: remove DMA_MASK_NONE

On Tue, Sep 22, 2020 at 03:40:00PM +0200, Christoph Hellwig wrote: > This value is only used by a PCMCIA driver and not very useful. > > Signed-off-by: Christoph Hellwig Acked-by: Dominik Brodowski

Re: [RESEND PATCH] sys_personality: Add optional arch hook arch_check_personality

On Mon, Jun 08, 2020 at 10:46:41AM +0100, Catalin Marinas wrote: > On Mon, Jun 08, 2020 at 10:49:25AM +0800, Wang ShaoBo wrote: > > Currently arm64 personality syscall uses wrapper __arm64_sys_personality > > to redirect to __arm64_sys_arm64_personality, it's easily confused, > > Whereas using an

[GIT PULL] pcmcia updates for v5.8

pccard_loop_tuple() static (2020-05-18 11:16:39 +0200) Two minor PCMCIA odd fixes, one replacing zero-length arrays with a flexible-array member, and one making a local function static. Thanks, Dominik Dominik Brodowski (1

Re: [PATCH] pcmcia: Replace zero-length array with flexible-array

On Thu, May 07, 2020 at 02:05:49PM -0500, Gustavo A. R. Silva wrote: > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

On Tue, Oct 22, 2019 at 05:17:12AM +1100, Michael . wrote: > Thank you Dominik for looking at this for us and passing it on. > > Good morning Bjorn, thank you also for looking into this for us and > thank you for CCing us into this as non of us are on the mailing list. > One question how do we

PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

On the basis of the additional information (thanks), there might be a more specific path to investigate: It is that the PCI code does not enumerate the second cardbus bridge PCI function in the more recent 4.19 kernel compared to the anvient (and working) 2.6 kernel. Namely, only one CardBus

Re: PCMCIA not working on Panasonic Toughbook CF-29

On Tue, Oct 15, 2019 at 05:04:28PM +1100, Michael . wrote: > Good afternoon kernel developers > Please accept my apology for contacting you directly about this. A > small group of friends, some of whom are CCed here, have come together > to try and find a solution to a problem that originated with

[PATCH] random: inform about bootloader-provided randomness

Inform how many bits of randomness were provided by the bootloader, and whether we trust that input. Signed-off-by: Dominik Brodowski Cc: Ard Biesheuvel Cc: Hsin-Yi Wang Cc: Stephen Boyd Cc: Rob Herring Cc: Theodore Ts'o Cc: Will Deacon diff --git a/drivers/char/random.c b/drivers/char

lockdep warning on thunderbolt docking

When connecting a thunderbolt-enabled docking station to my work laptop, the following lockdep warning is reported on v5.3.0-rc6+ as of Thursday morning (can look up the exact git id if so required): thunderbolt 0-1: new device found, vendor=0xd4 device=0xb070 thunderbolt 0-1: Dell WD19TB

Re: [PATCH v2 19/35] pcmcia: Use kmemdup rather than duplicating its implementation

ility, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. > > Signed-off-by: Fuqian Huang Acked-by: Dominik Brodowski Thanks, Dominik

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On Sun, May 12, 2019 at 03:18:16AM -0700, h...@zytor.com wrote: > > Couldn't this parsing of the .xattr-list file and the setting of the xattrs > > be done equivalently by the initramfs' /init? Why is kernel involvement > > actually required here? > > There are a lot of things that could/should

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote: > This proposal consists in marshaling pathnames and xattrs in a file called > .xattr-list. They are unmarshaled by the CPIO parser after all files have > been extracted. Couldn't this parsing of the .xattr-list file and the setting

Re: [PATCH] drivers: pcmcia: This patch fix the following checkpatch warning.

On Tue, Apr 16, 2019 at 08:45:44PM +0300, Mohan Kumar wrote: > Switch hardcoded function name with a reference to __func__ making the > code more maintainable Thanks for your patch. Are there any other patches pending to this driver? As noted in Kconfig, the TCIC host briges "are only found on a

Re: fs_context-related oops in mainline

On Fri, Mar 15, 2019 at 12:18:13PM +, Al Viro wrote: > On Fri, Mar 15, 2019 at 12:50:02PM +0100, Dominik Brodowski wrote: > > On Fri, Mar 15, 2019 at 11:44:45AM +, David Howells wrote: > > > Dominik Brodowski wrote: > > > > > > > [0.839322] RI

Re: fs_context-related oops in mainline

On Fri, Mar 15, 2019 at 11:44:45AM +, David Howells wrote: > Dominik Brodowski wrote: > > > [0.839322] RIP: 0010:sysfs_init_fs_context+0x82/0xd0 > > Could you load your kernel into gdb and then do: > > i li *sysfs_init_fs_context+0x82 Doesn't seem necess

Re: fs_context-related oops in mainline

On Fri, Mar 15, 2019 at 11:34:47AM +, Al Viro wrote: > On Fri, Mar 15, 2019 at 08:43:07AM +0100, Dominik Brodowski wrote: > > David, Al, > > > > commit 23bf1b6be9c2 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context") > > seems to have introduce

fs_context-related oops in mainline

David, Al, commit 23bf1b6be9c2 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context") seems to have introduced a bug; at least that's the commit I bisected the following oops down to: [0.827317] BUG: unable to handle kernel NULL pointer dereference at 0220 [0.829771] #PF

Re: [PATCH] x86/asm: Pin sensitive CR4 bits

On Tue, Feb 19, 2019 at 04:54:49PM -0800, Kees Cook wrote: > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index cb28e98a0659..7e0ea4470f8e 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -312,10 +312,16 @@ static __init int

Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max

On Thu, Jan 10, 2019 at 03:50:05PM +0100, Christian Brauner wrote: > On Tue, Jan 08, 2019 at 08:01:10AM +0100, Dominik Brodowski wrote: > > On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote: > > > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec

Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max

On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote: > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, > struct ctl_table *table, int > break; > if (neg) > continue; > +

Re: *powersave* governor shown despite disabled in configuration

On Mon, Dec 10, 2018 at 04:30:05PM +0100, Paul Menzel wrote: > Dear Linux folks, > > > With Linux 4.14.76, the scaling governor *powersave* is shown as > being available despite being disabled in the configuration. Which cpufreq driver do you use? Presumably intel_pstate? That driver exposes

Re: [PATCH] pcmcia: remove per-arch PCMCIA config entry

> > I will queue this up to my kbuild tree > along with Christoph's clean-up patch set. Acked-by: Dominik Brodowski Thanks, Dominik

Re: [PATCH] pcmcia: remove per-arch PCMCIA config entry

> > I will queue this up to my kbuild tree > along with Christoph's clean-up patch set. Acked-by: Dominik Brodowski Thanks, Dominik

Re: [patch V2 26/28] x86/speculation: Enable prctl mode for spectre_v2_user

On Sun, Nov 25, 2018 at 07:33:54PM +0100, Thomas Gleixner wrote: > + prctl - Indirect branch speculation is enabled, > + but mitigation can be enabled via prctl s/can be/is only/ or "must be". Thanks, Dominik

Re: [patch V2 26/28] x86/speculation: Enable prctl mode for spectre_v2_user

On Sun, Nov 25, 2018 at 07:33:54PM +0100, Thomas Gleixner wrote: > + prctl - Indirect branch speculation is enabled, > + but mitigation can be enabled via prctl s/can be/is only/ or "must be". Thanks, Dominik

Re: Linux 4.19.0 Build Error when CONFIG_ACPI not set.

n is within #ifdef CONFIG_ACPI/#endif conditional compile. > > Any ideas how to fix this? This isn't in 4.19.0, but in current mainline, and can be fixed by this patch which is already on its way upstream. https://patchwork.kernel.org/patch/10653593/ Thanks, Dominik Dat

Re: Linux 4.19.0 Build Error when CONFIG_ACPI not set.

n is within #ifdef CONFIG_ACPI/#endif conditional compile. > > Any ideas how to fix this? This isn't in 4.19.0, but in current mainline, and can be fixed by this patch which is already on its way upstream. https://patchwork.kernel.org/patch/10653593/ Thanks, Dominik Dat

[PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

While at it, add a few comments which config options #ifdef and #else statements refer to. Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute") Cc: Srinivas Pandruvada Cc: Rafael J. Wysocki Signed-off-by: Dominik Brodowski diff --git a/drivers/cpufreq/intel_

[PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

While at it, add a few comments which config options #ifdef and #else statements refer to. Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute") Cc: Srinivas Pandruvada Cc: Rafael J. Wysocki Signed-off-by: Dominik Brodowski diff --git a/drivers/cpufreq/intel_

Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

On Tue, Oct 23, 2018 at 12:17:28PM -0700, Srinivas Pandruvada wrote: > On Tue, 2018-10-23 at 20:54 +0200, Dominik Brodowski wrote: > > Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency > > attribute") > Thanks for the fix. > > > Cc: Srinivas

Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

On Tue, Oct 23, 2018 at 12:17:28PM -0700, Srinivas Pandruvada wrote: > On Tue, 2018-10-23 at 20:54 +0200, Dominik Brodowski wrote: > > Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency > > attribute") > Thanks for the fix. > > > Cc: Srinivas

[PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute") Cc: Srinivas Pandruvada Cc: Rafael J. Wysocki Cc: Len Brown Signed-off-by: Dominik Brodowski diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 49c0abf2d48f..50c569997

[PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute") Cc: Srinivas Pandruvada Cc: Rafael J. Wysocki Cc: Len Brown Signed-off-by: Dominik Brodowski diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 49c0abf2d48f..50c569997

Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol

On Sun, Mar 18, 2018 at 04:12:10PM +0100, Harald Welte wrote: > Hi Jia-Ju Bai, > > On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote: > > This is found by a static analysis tool named DCNS written by myself. > > nice catch! > > > Signed-off-by: Jia-Ju Bai > > Acked-by: Harald Welte

Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol

On Sun, Mar 18, 2018 at 04:12:10PM +0100, Harald Welte wrote: > Hi Jia-Ju Bai, > > On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote: > > This is found by a static analysis tool named DCNS written by myself. > > nice catch! > > > Signed-off-by: Jia-Ju Bai > > Acked-by: Harald Welte

Re: [PATCH] pcmcia: pcmcia_resource: Replace mdelay() with msleep()

On Mon, Jul 30, 2018 at 09:42:56PM +0800, Jia-Ju Bai wrote: > pcmcia_fixup_iowidth() and pcmcia_enable_device() are > never called in atomic context. > They call mdelay() to busily wait, which is not necessary. > mdelay() can be replaced with msleep(). > > This is found by a static analysis tool

Re: [PATCH] pcmcia: pcmcia_resource: Replace mdelay() with msleep()

On Mon, Jul 30, 2018 at 09:42:56PM +0800, Jia-Ju Bai wrote: > pcmcia_fixup_iowidth() and pcmcia_enable_device() are > never called in atomic context. > They call mdelay() to busily wait, which is not necessary. > mdelay() can be replaced with msleep(). > > This is found by a static analysis tool

Re: [PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges

On Sun, Sep 09, 2018 at 01:21:06AM +0200, Maciej S. Szmigiero wrote: > Currently, "disable_clkrun" yenta_socket module parameter is only > implemented for TI CardBus bridges. > Add also an implementation for Ricoh bridges that have the necessary > setting documented in publicly available

Re: [PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges

On Sun, Sep 09, 2018 at 01:21:06AM +0200, Maciej S. Szmigiero wrote: > Currently, "disable_clkrun" yenta_socket module parameter is only > implemented for TI CardBus bridges. > Add also an implementation for Ricoh bridges that have the necessary > setting documented in publicly available

[tip:x86/pti] x86/speculation: Simplify the CPU bug detection logic

Commit-ID: 8ecc4979b1bd9c94168e6fc92960033b7a951336 Gitweb: https://git.kernel.org/tip/8ecc4979b1bd9c94168e6fc92960033b7a951336 Author: Dominik Brodowski <li...@dominikbrodowski.net> AuthorDate: Tue, 22 May 2018 11:05:39 +0200 Committer: Thomas Gleixner <t...@linutronix.de>

[tip:x86/pti] x86/speculation: Simplify the CPU bug detection logic

Commit-ID: 8ecc4979b1bd9c94168e6fc92960033b7a951336 Gitweb: https://git.kernel.org/tip/8ecc4979b1bd9c94168e6fc92960033b7a951336 Author: Dominik Brodowski AuthorDate: Tue, 22 May 2018 11:05:39 +0200 Committer: Thomas Gleixner CommitDate: Wed, 23 May 2018 10:55:52 +0200 x86/speculation

Re: [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation

On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote: > If running on a system that performs dynamic SSBD mitigation, allow > userspace to request the mitigation for itself. This is implemented > as a prctl call, allowing the mitigation to be enabled or disabled at > will for this

Re: [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation

On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote: > If running on a system that performs dynamic SSBD mitigation, allow > userspace to request the mitigation for itself. This is implemented > as a prctl call, allowing the mitigation to be enabled or disabled at > will for this

[PATCH] x86/speculation: Simplify the CPU bug detection logic

in cpu_no_spec_store_bypass as well. Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> --- arch/x86/kernel/cpu/common.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 78decc

[PATCH] x86/speculation: Simplify the CPU bug detection logic

in cpu_no_spec_store_bypass as well. Signed-off-by: Dominik Brodowski --- arch/x86/kernel/cpu/common.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 78decc3e3067..2fcc1fbf11b0 100644 --- a/arch

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote: > On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote: > > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote: > > > I agree it would be nicer if it had a wrapper that took a pt_regs, eve

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote: > On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote: > > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote: > > > I agree it would be nicer if it had a wrapper that took a pt_regs, eve

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

On Tue, May 15, 2018 at 10:53:51AM +0100, Mark Rutland wrote: > On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote: > > On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote: > > > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote: > > &

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

On Tue, May 15, 2018 at 10:53:51AM +0100, Mark Rutland wrote: > On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote: > > On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote: > > > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote: > > &

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote: > I agree it would be nicer if it had a wrapper that took a pt_regs, even > if it does nothing with it. > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd > need a ksys_ni_syscall() for our traps.c logic, and

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote: > I agree it would be nicer if it had a wrapper that took a pt_regs, even > if it does nothing with it. > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd > need a ksys_ni_syscall() for our traps.c logic, and

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

, sys_xyzyyz()) directly. * Instead, use one of the functions which work equivalently, such as * the ksys_xyzyyz() functions prototyped below. */ Once you have done so, feel free to add my Reviewed-by: Dominik Brodowski <li...@dominikbrodowski.net> tag to this patch. Thanks, Dominik

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

, sys_xyzyyz()) directly. * Instead, use one of the functions which work equivalently, such as * the ksys_xyzyyz() functions prototyped below. */ Once you have done so, feel free to add my Reviewed-by: Dominik Brodowski tag to this patch. Thanks, Dominik

Re: [PATCH 18/18] arm64: implement syscall wrappers

On Mon, May 14, 2018 at 10:46:40AM +0100, Mark Rutland wrote: > Note that we play games with sys_ni_syscall(). It can't be defined with > SYSCALL_DEFINE0() because we must avoid the possibility of error > injection. Additionally, there are a couple of locations where we need > to call it from C

Re: [PATCH 18/18] arm64: implement syscall wrappers

On Mon, May 14, 2018 at 10:46:40AM +0100, Mark Rutland wrote: > Note that we play games with sys_ni_syscall(). It can't be defined with > SYSCALL_DEFINE0() because we must avoid the possibility of error > injection. Additionally, there are a couple of locations where we need > to call it from C

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn) > +{ > + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1], > +regs->regs[2], regs->regs[3], > +regs->regs[4], regs->regs[5]); > +} Any specific

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn) > +{ > + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1], > +regs->regs[2], regs->regs[3], > +regs->regs[4], regs->regs[5]); > +} Any specific

[PATCH] perf: update to new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update the perf scripts/utils/tests which need to be aware of the syscall stub naming accordingly. Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c b/tools/perf/arch/p

[PATCH] Documentation: updates for new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update stack traces and similar instances in the documentation to avoid sources for confusion. Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-gui

[PATCH] Documentation: updates for new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update stack traces and similar instances in the documentation to avoid sources for confusion. Signed-off-by: Dominik Brodowski diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index

[PATCH] perf: update to new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update the perf scripts/utils/tests which need to be aware of the syscall stub naming accordingly. Signed-off-by: Dominik Brodowski diff --git a/tools/perf/arch/powerpc/util/sym-handling.c b/tools/perf/arch/powerpc/util/sym-handling.c index

Re: [PATCH v3] tracing/x86: Update syscall trace events to handle new prefixed syscall func names

y: Arnaldo Carvalho de Melo <a...@redhat.com> > Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct > pt_regs-based sys_*() to __x64_sys_*()") > Signed-off-by: Steven Rostedt (VMware) <rost...@goodmis.org> Acked-by: Dominik Brodowski <li...@dominikbrodowski.net>

Re: [PATCH v3] tracing/x86: Update syscall trace events to handle new prefixed syscall func names

uot;syscalls/core, syscalls/x86: Rename struct > pt_regs-based sys_*() to __x64_sys_*()") > Signed-off-by: Steven Rostedt (VMware) Acked-by: Dominik Brodowski

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

> Added back original compare to not miss 32bit kernel syscalls s/32bit/32bit and 0-parameter syscalls. Looks good otherwise. Thanks, Dominik

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

> Added back original compare to not miss 32bit kernel syscalls s/32bit/32bit and 0-parameter syscalls. Looks good otherwise. Thanks, Dominik

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

On Tue, Apr 17, 2018 at 12:39:27PM -0400, Steven Rostedt wrote: > > > names, they do not match the default compare algorithm. As this was a > > > problem for power pc, the algorithm can be overwritten by the > > > architecture. > > > The solution is to have x86 have its own algorithm to do the

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

On Tue, Apr 17, 2018 at 12:39:27PM -0400, Steven Rostedt wrote: > > > names, they do not match the default compare algorithm. As this was a > > > problem for power pc, the algorithm can be overwritten by the > > > architecture. > > > The solution is to have x86 have its own algorithm to do the

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

Steven, On Tue, Apr 17, 2018 at 11:54:40AM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Arnaldo noticed that the latest kernel is missing the syscall event system > directory in x86. I bisected it down to d5a00528b58c ("syscalls/core, > syscalls/x86:

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

Steven, On Tue, Apr 17, 2018 at 11:54:40AM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Arnaldo noticed that the latest kernel is missing the syscall event system > directory in x86. I bisected it down to d5a00528b58c ("syscalls/core, > syscalls/x86: Rename struct

Re: Linux 4.17-rc1

On Mon, Apr 16, 2018 at 11:01:57AM +0200, Geert Uytterhoeven wrote: > On Mon, Apr 16, 2018 at 3:55 AM, Linus Torvalds > wrote: > > We actually have a fair amount of other removal and cleanups too. I > > was somewhat pleasantly surprised by the number of pull

Re: Linux 4.17-rc1

On Mon, Apr 16, 2018 at 11:01:57AM +0200, Geert Uytterhoeven wrote: > On Mon, Apr 16, 2018 at 3:55 AM, Linus Torvalds > wrote: > > We actually have a fair amount of other removal and cleanups too. I > > was somewhat pleasantly surprised by the number of pull requests that > > actually ended up

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up syscall stub naming convention

Commit-ID: e145242ea0df6b7d28fd7186e61d6840fa4bb06e Gitweb: https://git.kernel.org/tip/e145242ea0df6b7d28fd7186e61d6840fa4bb06e Author: Dominik Brodowski <li...@dominikbrodowski.net> AuthorDate: Mon, 9 Apr 2018 12:51:42 +0200 Committer: Ingo Molnar <mi...@kernel.org> Commit

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up syscall stub naming convention

Commit-ID: e145242ea0df6b7d28fd7186e61d6840fa4bb06e Gitweb: https://git.kernel.org/tip/e145242ea0df6b7d28fd7186e61d6840fa4bb06e Author: Dominik Brodowski AuthorDate: Mon, 9 Apr 2018 12:51:42 +0200 Committer: Ingo Molnar CommitDate: Mon, 9 Apr 2018 16:47:27 +0200 syscalls/core

[tip:x86/asm] syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

Commit-ID: c76fc98260751e71c884dc1a18a07e427ef033b5 Gitweb: https://git.kernel.org/tip/c76fc98260751e71c884dc1a18a07e427ef033b5 Author: Dominik Brodowski <li...@dominikbrodowski.net> AuthorDate: Mon, 9 Apr 2018 12:51:45 +0200 Committer: Ingo Molnar <mi...@kernel.org> Commit

[tip:x86/asm] syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

Commit-ID: c76fc98260751e71c884dc1a18a07e427ef033b5 Gitweb: https://git.kernel.org/tip/c76fc98260751e71c884dc1a18a07e427ef033b5 Author: Dominik Brodowski AuthorDate: Mon, 9 Apr 2018 12:51:45 +0200 Committer: Ingo Molnar CommitDate: Mon, 9 Apr 2018 16:47:28 +0200 syscalls/x86: Adapt

[tip:x86/asm] syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()

Commit-ID: d5a00528b58cdb2c71206e18bd021e34c4eab878 Gitweb: https://git.kernel.org/tip/d5a00528b58cdb2c71206e18bd021e34c4eab878 Author: Dominik Brodowski <li...@dominikbrodowski.net> AuthorDate: Mon, 9 Apr 2018 12:51:44 +0200 Committer: Ingo Molnar <mi...@kernel.org> Commit

[tip:x86/asm] syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()

Commit-ID: d5a00528b58cdb2c71206e18bd021e34c4eab878 Gitweb: https://git.kernel.org/tip/d5a00528b58cdb2c71206e18bd021e34c4eab878 Author: Dominik Brodowski AuthorDate: Mon, 9 Apr 2018 12:51:44 +0200 Committer: Ingo Molnar CommitDate: Mon, 9 Apr 2018 16:47:28 +0200 syscalls/core

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

Commit-ID: 5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92 Gitweb: https://git.kernel.org/tip/5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92 Author: Dominik Brodowski <li...@dominikbrodowski.net> AuthorDate: Mon, 9 Apr 2018 12:51:43 +0200 Committer: Ingo Molnar <mi...@kernel.org> Commit

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

Commit-ID: 5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92 Gitweb: https://git.kernel.org/tip/5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92 Author: Dominik Brodowski AuthorDate: Mon, 9 Apr 2018 12:51:43 +0200 Committer: Ingo Molnar CommitDate: Mon, 9 Apr 2018 16:47:28 +0200 syscalls/core

[PATCHv2 4/4] syscalls/x86: adapt syscall_wrapper.h to the new syscall stub naming convention

edhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> --- arch/x86/include/asm/syscall_wrapper.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) dif

[PATCHv2 4/4] syscalls/x86: adapt syscall_wrapper.h to the new syscall stub naming convention

Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Dominik Brodowski --- arch/x86/include/asm/syscall_wrapper.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm

[PATCHv2 2/4] syscalls: clean up compat syscall stub naming convention

enko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> --- Documentation/p

[PATCHv2 2/4] syscalls: clean up compat syscall stub naming convention

ro Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Dominik Brodowski --- Documentation/process/adding-syscalls.rst | 4 +- arch/x86/entry/syscalls/sysc

[PATCHv2 1/4] syscalls: clean up syscall stub naming convention

Borislav Petkov <b...@alien8.de> Cc: Brian Gerst <brge...@gmail.com> Cc: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@

  1   2   3   4   5   6   7   8   9   10   >