[RFC PATCH v2 0/7] AC97 device/driver model revamp

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 And now it transformed into this RFC, which would bring a ground for AC'97 devices closer to the linux

[RFC PATCH v2 0/7] AC97 device/driver model revamp

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 And now it transformed into this RFC, which would bring a ground for AC'97 devices closer to the linux

[RFC PATCH v2 1/7] ALSA: ac97: split out the generic ac97 registers

Split out from the ac97_codec.h the ac97 generic registers, which can be used by a codec, typically a generic ac97 codec, and by the ac97 bus, to scan an ac97 AC-Link. This split encompasses all the AC97 standard registers, but not the codec specific ones. In order to have a clean split between

[RFC PATCH v2 1/7] ALSA: ac97: split out the generic ac97 registers

Split out from the ac97_codec.h the ac97 generic registers, which can be used by a codec, typically a generic ac97 codec, and by the ac97 bus, to scan an ac97 AC-Link. This split encompasses all the AC97 standard registers, but not the codec specific ones. In order to have a clean split between

[RFC PATCH v2 3/7] ASoC: add new ac97 bus support

Add the new ac97 bus support, with ac97 bus automatic probing. Signed-off-by: Robert Jarzmik --- sound/Kconfig | 2 ++ sound/Makefile| 1 + sound/soc/Kconfig | 4 3 files changed, 7 insertions(+) diff --git a/sound/Kconfig b/sound/Kconfig index

pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Hi, your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree machines") causes various non-devicetree systems to fail with the following error messages when running a pxa_defconfig image. During boot: Can't request reset_gpio At reboot: reboot: Restarting system

[RFC PATCH v2 3/7] ASoC: add new ac97 bus support

Add the new ac97 bus support, with ac97 bus automatic probing. Signed-off-by: Robert Jarzmik --- sound/Kconfig | 2 ++ sound/Makefile| 1 + sound/soc/Kconfig | 4 3 files changed, 7 insertions(+) diff --git a/sound/Kconfig b/sound/Kconfig index 5a240e050ae6..c7e1cbe84951 100644

pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Hi, your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree machines") causes various non-devicetree systems to fail with the following error messages when running a pxa_defconfig image. During boot: Can't request reset_gpio At reboot: reboot: Restarting system

Re: [PATCH v4 1/4] dt-bindings: sound: add bindings for the max9860 codec

On Sat, May 14, 2016 at 11:09:38PM +0200, Peter Rosin wrote: > This adds the device tree binding documentation for the Maxim Integrated > MAX9860 mono audio voice codec. Please submit patches using subject lines reflecting the style for the subsystem. This makes it easier for people to identify

Re: [PATCH v4 1/4] dt-bindings: sound: add bindings for the max9860 codec

On Sat, May 14, 2016 at 11:09:38PM +0200, Peter Rosin wrote: > This adds the device tree binding documentation for the Maxim Integrated > MAX9860 mono audio voice codec. Please submit patches using subject lines reflecting the style for the subsystem. This makes it easier for people to identify

[PATCH v3] media: Media Device Allocator API

Media Device Allocator API to allows multiple drivers share a media device. Using this API, drivers can allocate a media device with the shared struct device as the key. Once the media device is allocated by a driver, other drivers can get a reference to it. The media device is released when all

[PATCH v3] media: Media Device Allocator API

Media Device Allocator API to allows multiple drivers share a media device. Using this API, drivers can allocate a media device with the shared struct device as the key. Once the media device is allocated by a driver, other drivers can get a reference to it. The media device is released when all

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote: > On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: > > > > Amended and force-pushed... > > Ok, I'll ignore that branch for now, in the hopes that there will be > actual testing success. Please send a full

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote: > On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: > > > > Amended and force-pushed... > > Ok, I'll ignore that branch for now, in the hopes that there will be > actual testing success. Please send a full pull request at that point,

Re: [RESEND PATCH 5/6] ASoC: cdn-dp: Add cdn DP codec driver

On Fri, May 27, 2016 at 06:45:41PM +0800, Chris Zhong wrote: > codec driver get some interfaces from cdn-dp driver, than using those > to set DP audio formats, corresponding to alsa formats. I'm not seeing anything Rockchip specific in here... DisplayPort is backwards compatible with HDMI,

Re: [RESEND PATCH 5/6] ASoC: cdn-dp: Add cdn DP codec driver

On Fri, May 27, 2016 at 06:45:41PM +0800, Chris Zhong wrote: > codec driver get some interfaces from cdn-dp driver, than using those > to set DP audio formats, corresponding to alsa formats. I'm not seeing anything Rockchip specific in here... DisplayPort is backwards compatible with HDMI,

[PATCH] reiserfs: avoid uninitialized variable use

I got this warning on an ARM64 allmodconfig build with gcc-5.3: fs/reiserfs/ibalance.c: In function 'balance_internal': fs/reiserfs/ibalance.c:1158:3: error: 'new_insert_key' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy(new_insert_key_addr, _insert_key,

[PATCH] reiserfs: avoid uninitialized variable use

I got this warning on an ARM64 allmodconfig build with gcc-5.3: fs/reiserfs/ibalance.c: In function 'balance_internal': fs/reiserfs/ibalance.c:1158:3: error: 'new_insert_key' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy(new_insert_key_addr, _insert_key,

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Fri, May 27, 2016 at 1:04 PM, Arnd Bergmann wrote: > > In fact, the patch that I have in my private tree that was hiding the > warning for me on x86 is one that removes all instances of IS_ERR_VALUE() > with arguments other than 'unsigned long', see http://pastebin.com/uYa2mkgC

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Fri, May 27, 2016 at 1:04 PM, Arnd Bergmann wrote: > > In fact, the patch that I have in my private tree that was hiding the > warning for me on x86 is one that removes all instances of IS_ERR_VALUE() > with arguments other than 'unsigned long', see http://pastebin.com/uYa2mkgC > for

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:02 PM, Andrew Morton wrote: On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" wrote: I hope we consider this direction, too. Yang, Could you think about this? Thanks a lot for the suggestion. Sorry for the late reply, I was busy on preparing patches. I do

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:02 PM, Andrew Morton wrote: On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" wrote: I hope we consider this direction, too. Yang, Could you think about this? Thanks a lot for the suggestion. Sorry for the late reply, I was busy on preparing patches. I do agree this is a

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: >> Right, I know, it's aesthetically much nicer that way, but I really >> want to stay totally paranoid and keep seccomp absolutely first on the >> path. >> >> How about this: we'll use this patch as-is for now, since

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: >> Right, I know, it's aesthetically much nicer that way, but I really >> want to stay totally paranoid and keep seccomp absolutely first on the >> path. >> >> How about this: we'll use this patch as-is for now, since I'd like to >> be able

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Friday, May 27, 2016 10:23:00 AM CEST Linus Torvalds wrote: > On Fri, May 27, 2016 at 5:33 AM, Arnd Bergmann wrote: > > > > > > gcc can not always figure out which code is only used in an error > > condition an assignment to indirect argument is only done after the > > use of

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Friday, May 27, 2016 10:23:00 AM CEST Linus Torvalds wrote: > On Fri, May 27, 2016 at 5:33 AM, Arnd Bergmann wrote: > > > > > > gcc can not always figure out which code is only used in an error > > condition an assignment to indirect argument is only done after the > > use of IS_ERR() catches

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" wrote: > >> > >> I hope we consider this direction, too. > > > > Yang, Could you think about this? > > Thanks a lot for the suggestion. Sorry for the late reply, I was busy on > preparing patches. I do agree this is a

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" wrote: > >> > >> I hope we consider this direction, too. > > > > Yang, Could you think about this? > > Thanks a lot for the suggestion. Sorry for the late reply, I was busy on > preparing patches. I do agree this is a direction we should look

[PATCH V2 1/2] soc: brcmstb: Add Product ID and Family ID helper functions

Signed-off-by: Al Cooper --- drivers/soc/brcmstb/common.c| 12 include/linux/soc/brcmstb/brcmstb.h | 10 ++ 2 files changed, 22 insertions(+) diff --git a/drivers/soc/brcmstb/common.c b/drivers/soc/brcmstb/common.c index 94e7335..454f4c2 100644

[PATCH V2 1/2] soc: brcmstb: Add Product ID and Family ID helper functions

Signed-off-by: Al Cooper --- drivers/soc/brcmstb/common.c| 12 include/linux/soc/brcmstb/brcmstb.h | 10 ++ 2 files changed, 22 insertions(+) diff --git a/drivers/soc/brcmstb/common.c b/drivers/soc/brcmstb/common.c index 94e7335..454f4c2 100644 ---

[PATCH V2 0/2] Add Broadcom USB PHY driver for Broadcom STB SoCs

Add Broadcom USB PHY driver for Broadcom STB SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. NOTE: An unrelated patch is in the pipline to move the file drivers/soc/brcmstb/common.c to

[PATCH V2 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

Add a new USB Phy driver for Broadcom STB SoCs. This driver supports all Broadcom STB ARM SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports the Broadcom UDC gadget driver.

[PATCH V2 0/2] Add Broadcom USB PHY driver for Broadcom STB SoCs

Add Broadcom USB PHY driver for Broadcom STB SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. NOTE: An unrelated patch is in the pipline to move the file drivers/soc/brcmstb/common.c to

[PATCH V2 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

Add a new USB Phy driver for Broadcom STB SoCs. This driver supports all Broadcom STB ARM SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports the Broadcom UDC gadget driver.

Re: [PATCH] oom_reaper: don't call mmput_async() on uninitialized mm

On Fri, 27 May 2016 10:10:59 +0200 Michal Hocko wrote: > On Fri 27-05-16 10:00:48, Arnd Bergmann wrote: > > The change to the oom_reaper to hold a mutex inside __oom_reap_task() > > accidentally started calling mmput_async() on the local > > mm before that variable got

Re: [PATCH] oom_reaper: don't call mmput_async() on uninitialized mm

On Fri, 27 May 2016 10:10:59 +0200 Michal Hocko wrote: > On Fri 27-05-16 10:00:48, Arnd Bergmann wrote: > > The change to the oom_reaper to hold a mutex inside __oom_reap_task() > > accidentally started calling mmput_async() on the local > > mm before that variable got initialized, as reported

[PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Removing P2P interface is handled by sending a proper request to the firmware. On success firmware triggers an event and driver's handler removes a matching interface. However on event timeout we remove interface directly from the cfg80211 callback. Current code doesn't handle this case correctly

Re: [PATCH v4 3/4] iio: stx104: Allow build for X86_64

On Fri, May 27, 2016 at 11:20:57AM -0700, Guenter Roeck wrote: >On Mon, May 23, 2016 at 08:31:07PM -0400, William Breathitt Gray wrote: >> With the introduction of the ISA_BUS_API Kconfig option, ISA-style >> drivers may be built for X86_64 architectures. This patch changes the >> ISA Kconfig

Re: [PATCH v4 3/4] iio: stx104: Allow build for X86_64

On Fri, May 27, 2016 at 11:20:57AM -0700, Guenter Roeck wrote: >On Mon, May 23, 2016 at 08:31:07PM -0400, William Breathitt Gray wrote: >> With the introduction of the ISA_BUS_API Kconfig option, ISA-style >> drivers may be built for X86_64 architectures. This patch changes the >> ISA Kconfig

[PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Removing P2P interface is handled by sending a proper request to the firmware. On success firmware triggers an event and driver's handler removes a matching interface. However on event timeout we remove interface directly from the cfg80211 callback. Current code doesn't handle this case correctly

Re: linux-next: build warning after merge of the akpm-current tree

On Fri, 27 May 2016 13:07:10 +1000 Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > mm/oom_kill.c: In function '__oom_reap_task': > mm/oom_kill.c:537:2: warning:

Re: linux-next: build warning after merge of the akpm-current tree

On Fri, 27 May 2016 13:07:10 +1000 Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > mm/oom_kill.c: In function '__oom_reap_task': > mm/oom_kill.c:537:2: warning: 'mm' may be used

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On May 27, 2016 11:42 AM, "Kees Cook" wrote: > > On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: > > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: > >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On May 27, 2016 11:42 AM, "Kees Cook" wrote: > > On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: > > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: > >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski > >> wrote: > >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: > One

Re: fsl-dcu not works on latest "drm-next"

On Fri, May 27, 2016 at 10:36:21AM -0700, Stefan Agner wrote: > On 2016-05-27 05:20, Mark Brown wrote: > > That's another way of addressing it of course, but unless the register > > map actually is sparse it's probably still sensible to send the > > conversion to flat cache as a fix. > The

Re: fsl-dcu not works on latest "drm-next"

On Fri, May 27, 2016 at 10:36:21AM -0700, Stefan Agner wrote: > On 2016-05-27 05:20, Mark Brown wrote: > > That's another way of addressing it of course, but unless the register > > map actually is sparse it's probably still sensible to send the > > conversion to flat cache as a fix. > The

[GIT PULL resend] vfs update for 4.7

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git d_real This fixes hard linked unix sockets on overlayfs and consolidates the d_real/d_select_inode API as well as some documentation cleanups. Thanks, Miklos --- Miklos Szeredi (5): vfs: add

[GIT PULL resend] vfs update for 4.7

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git d_real This fixes hard linked unix sockets on overlayfs and consolidates the d_real/d_select_inode API as well as some documentation cleanups. Thanks, Miklos --- Miklos Szeredi (5): vfs: add

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: > > Amended and force-pushed... Ok, I'll ignore that branch for now, in the hopes that there will be actual testing success. Please send a full pull request at that point, ok? Linus

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: > > Amended and force-pushed... Ok, I'll ignore that branch for now, in the hopes that there will be actual testing success. Please send a full pull request at that point, ok? Linus

Re: [PATCH] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const >> > char *name, >> > const void *value, size_t size, int flags) >> > { >> >if (!strcmp(name,

Re: [PATCH] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const >> > char *name, >> > const void *value, size_t size, int flags) >> > { >> >if (!strcmp(name, XATTR_NAME_CAPS)) {

[GIT PULL] platform-drivers-x86 for 4.7-1

Hi Linus, The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.7-1 for you to fetch

[GIT PULL] platform-drivers-x86 for 4.7-1

Hi Linus, The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.7-1 for you to fetch

[GIT PULL] overlayfs update for 4.7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus The meat of this is a change to use the mounter's credentials for operations that require elevated privileges (such as whiteout creation). This fixes behavior under user namespaces as

[GIT PULL] overlayfs update for 4.7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus The meat of this is a change to use the mounter's credentials for operations that require elevated privileges (such as whiteout creation). This fixes behavior under user namespaces as

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:34:34PM -0700, Linus Torvalds wrote: > On Fri, May 27, 2016 at 12:26 PM, Al Viro wrote: > > > > Umm... Would something along the lines of [...] > > Sure. That makes me go "ahh, ok, I see why". Amended and force-pushed...

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:34:34PM -0700, Linus Torvalds wrote: > On Fri, May 27, 2016 at 12:26 PM, Al Viro wrote: > > > > Umm... Would something along the lines of [...] > > Sure. That makes me go "ahh, ok, I see why". Amended and force-pushed...

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:03:37PM -0700, Casey Schaufler wrote: > I haven't actually seen the problem, but I've been having > real trouble getting a systemd configuration working properly. > The quickest validation will probably be coming from Seung-Woo Kim, > who reported the issue initially. I

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

From: Nick Alcock Date: Fri, 27 May 2016 14:19:27 +0100 > The only difference between the two series above is that in the crashing > series, the ka_restorer stub functions __rt_sigreturn_stub and > __sigreturn_stub (on sparc32) and __rt_sigreturn_stub (on sparc64) get >

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:03:37PM -0700, Casey Schaufler wrote: > I haven't actually seen the problem, but I've been having > real trouble getting a systemd configuration working properly. > The quickest validation will probably be coming from Seung-Woo Kim, > who reported the issue initially. I

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

From: Nick Alcock Date: Fri, 27 May 2016 14:19:27 +0100 > The only difference between the two series above is that in the crashing > series, the ka_restorer stub functions __rt_sigreturn_stub and > __sigreturn_stub (on sparc32) and __rt_sigreturn_stub (on sparc64) get > stack-protected; in the

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:26 PM, Al Viro wrote: > > Umm... Would something along the lines of [...] Sure. That makes me go "ahh, ok, I see why". Linus

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On 5/27/2016 5:05 AM, Peter Zijlstra wrote: On Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote: On 5/26/2016 10:19 AM, Peter Zijlstra wrote: --- a/arch/tile/lib/spinlock_32.c +++ b/arch/tile/lib/spinlock_32.c @@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock if

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:26 PM, Al Viro wrote: > > Umm... Would something along the lines of [...] Sure. That makes me go "ahh, ok, I see why". Linus

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On 5/27/2016 5:05 AM, Peter Zijlstra wrote: On Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote: On 5/26/2016 10:19 AM, Peter Zijlstra wrote: --- a/arch/tile/lib/spinlock_32.c +++ b/arch/tile/lib/spinlock_32.c @@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock if

Re: [PATCH 1/2] locking/pvqspinlock: Fix missed PV wakeup problem

On 05/27/2016 03:43 AM, Boqun Feng wrote: Hi Waiman, On Thu, May 26, 2016 at 02:21:57PM -0400, Waiman Long wrote: Currently, calling pv_hash() and setting _Q_SLOW_VAL is only done once for any pv_node. It is either in pv_kick_node() or in pv_wait_head_or_lock(). Because of lock stealing, a

Re: [PATCH 1/2] locking/pvqspinlock: Fix missed PV wakeup problem

On 05/27/2016 03:43 AM, Boqun Feng wrote: Hi Waiman, On Thu, May 26, 2016 at 02:21:57PM -0400, Waiman Long wrote: Currently, calling pv_hash() and setting _Q_SLOW_VAL is only done once for any pv_node. It is either in pv_kick_node() or in pv_wait_head_or_lock(). Because of lock stealing, a

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:01:05PM -0700, Linus Torvalds wrote: > Al, if you want Casey to help test, I think you should write out the > full git repository address, rather than just say "See > vfs.git#smack-fix". > > Anybody who isn't used to pulling for you will just wonder where you > keep

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 12:01:05PM -0700, Linus Torvalds wrote: > Al, if you want Casey to help test, I think you should write out the > full git repository address, rather than just say "See > vfs.git#smack-fix". > > Anybody who isn't used to pulling for you will just wonder where you > keep

[GIT PULL] UML updates for v4.7-rc1

Linus, The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99: Linux 4.6-rc7 (2016-05-08 14:38:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.7-rc1 for you to fetch changes up to

[GIT PULL] UML updates for v4.7-rc1

Linus, The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99: Linux 4.6-rc7 (2016-05-08 14:38:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.7-rc1 for you to fetch changes up to

[GIT PULL] UBI/UBIFS updates for v4.7-rc1

Linus, The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4: Linux 4.6-rc6 (2016-05-01 15:52:31 -0700) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.7-rc1 for you to fetch changes up to

[GIT PULL] UBI/UBIFS updates for v4.7-rc1

Linus, The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4: Linux 4.6-rc6 (2016-05-01 15:52:31 -0700) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.7-rc1 for you to fetch changes up to

Re: Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, 27 May 2016, Chung-Geol Kim wrote: > >On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: > >> There is a double free problem in the usb driver. > > > >Which driver? > When I using the USB OTG Storage, this issue happened. > When remove the OTG Storage, it reproduced

Re: Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, 27 May 2016, Chung-Geol Kim wrote: > >On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: > >> There is a double free problem in the usb driver. > > > >Which driver? > When I using the USB OTG Storage, this issue happened. > When remove the OTG Storage, it reproduced

Re: [PATCH] user-namespaced file capabilities - now with even more magic

Quoting Eric W. Biederman (ebied...@xmission.com): > > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const > > char *name, > >const void *value, size_t size, int flags) > > { > > if (!strcmp(name, XATTR_NAME_CAPS)) { > > - if

Re: [PATCH] user-namespaced file capabilities - now with even more magic

Quoting Eric W. Biederman (ebied...@xmission.com): > > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const > > char *name, > >const void *value, size_t size, int flags) > > { > > if (!strcmp(name, XATTR_NAME_CAPS)) { > > - if

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On 5/27/2016 11:51 AM, Al Viro wrote: > On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: > >>> After commit, "b968091 security_d_instantiate(): move to the point prior to >>> attaching dentry to inode", booting on system with >>> systemd and security smack, following kernel panic occurs.

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On 5/27/2016 11:51 AM, Al Viro wrote: > On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: > >>> After commit, "b968091 security_d_instantiate(): move to the point prior to >>> attaching dentry to inode", booting on system with >>> systemd and security smack, following kernel panic occurs.

[PATCH V2] brcmfmac: fix setting AP channel with new firmwares

Firmware for new chipsets is based on a new major version of code internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was based on 7.35.177.56. Currently setting AP 5 GHz channel doesn't work reliably with

[PATCH V2] brcmfmac: fix setting AP channel with new firmwares

Firmware for new chipsets is based on a new major version of code internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was based on 7.35.177.56. Currently setting AP 5 GHz channel doesn't work reliably with

Re: [PATCH] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Root in a user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any > unprivileged user on the host could map his own uid to root in a > namespace, write the xattr, and execute the file with

Re: [PATCH] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Root in a user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any > unprivileged user on the host could map his own uid to root in a > namespace, write the xattr, and execute the file with privilege on the >

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 11:51 AM, Al Viro wrote: > On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: >> There is a fairly straightforward way to handle that - do to ->setxattr() >> what we'd already done to ->getxattr(). See vfs.git#smack-fix. Warning: >> it's

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 11:51 AM, Al Viro wrote: > On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: >> There is a fairly straightforward way to handle that - do to ->setxattr() >> what we'd already done to ->getxattr(). See vfs.git#smack-fix. Warning: >> it's only build-tested. I'm

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: > > After commit, "b968091 security_d_instantiate(): move to the point prior to > > attaching dentry to inode", booting on system with > > systemd and security smack, following kernel panic occurs. > > /* >

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 04:11:41PM +0100, Al Viro wrote: > > After commit, "b968091 security_d_instantiate(): move to the point prior to > > attaching dentry to inode", booting on system with > > systemd and security smack, following kernel panic occurs. > > /* >

[PATCH] xen: xenbus: Remove create_workqueue

With concurrency managed workqueues, use of dedicated workqueues can be replaced by using system_wq. Drop xenbus_frontend_wq by using system_wq. Since there is only a single work item, increase of concurrency level by switching to system_wq should not break anything. Since the work item could be

[PATCH] xen: xenbus: Remove create_workqueue

With concurrency managed workqueues, use of dedicated workqueues can be replaced by using system_wq. Drop xenbus_frontend_wq by using system_wq. Since there is only a single work item, increase of concurrency level by switching to system_wq should not break anything. Since the work item could be

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: One problem with seccomp was that ptrace could be used to change a

[PATCH 1/1] perf/x86/intel/uncore: remove SBOX support for Broadwell server

From: Kan Liang There was a report that on some Broadwell-EP system writing any bit of the SBOX PMU initialization MSR would #GP at boot. This did not happen on all systems. My test systems booted fine. Considering both DE and EP may have such issue, this patch removes SBOX

[PATCH 1/1] perf/x86/intel/uncore: remove SBOX support for Broadwell server

From: Kan Liang There was a report that on some Broadwell-EP system writing any bit of the SBOX PMU initialization MSR would #GP at boot. This did not happen on all systems. My test systems booted fine. Considering both DE and EP may have such issue, this patch removes SBOX support for all

[GIT PULL] Block fixes for 4.7-rc1

Hi Linus, A set of fixes that wasn't included in the first merge window pull request. This pull request contains: - A set of NVMe fixes from Keith, and one from Nic for the integrity side of it. - Fix from Ming, clearing ->mq_ops if we don't successfully setup a queue for multiqueue. - A

[GIT PULL] Block fixes for 4.7-rc1

Hi Linus, A set of fixes that wasn't included in the first merge window pull request. This pull request contains: - A set of NVMe fixes from Keith, and one from Nic for the integrity side of it. - Fix from Ming, clearing ->mq_ops if we don't successfully setup a queue for multiqueue. - A

Re: [PATCH] z3fold: avoid modifying HEADLESS page and minor cleanup

On Fri, May 27, 2016 at 12:06 PM, Vitaly Wool wrote: > This patch fixes erroneous z3fold header access in a HEADLESS page > in reclaim function, and changes one remaining direct > handle-to-buddy conversion to use the appropriate helper. > > Signed-off-by: Vitaly Wool

Re: [PATCH] z3fold: avoid modifying HEADLESS page and minor cleanup

On Fri, May 27, 2016 at 12:06 PM, Vitaly Wool wrote: > This patch fixes erroneous z3fold header access in a HEADLESS page > in reclaim function, and changes one remaining direct > handle-to-buddy conversion to use the appropriate helper. > > Signed-off-by: Vitaly Wool Reviewed-by: Dan Streetman

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Wed, May 25, 2016 at 11:46:35AM -0700, Frank Rowand wrote: > On 5/25/2016 10:48 AM, Mark Brown wrote: > > Sometimes the best thing to do is remove the behaviour, some of these > Yes. And I have not formed an opinion on whether the existing > behavior should be kept, deprecated, or removed.

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Wed, May 25, 2016 at 11:46:35AM -0700, Frank Rowand wrote: > On 5/25/2016 10:48 AM, Mark Brown wrote: > > Sometimes the best thing to do is remove the behaviour, some of these > Yes. And I have not formed an opinion on whether the existing > behavior should be kept, deprecated, or removed.

<    1   2   3   4   5   6   7   8   9   10   >