Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 6:56 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >> On 12/19/16 5:25 PM, Andy Lutomirski wrote: >>> net.socket_create_filter = "none": no filter >>> net.socket_create_filter = "bpf:baadf00d": bpf filter >>>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 6:56 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >> On 12/19/16 5:25 PM, Andy Lutomirski wrote: >>> net.socket_create_filter = "none": no filter >>> net.socket_create_filter = "bpf:baadf00d": bpf filter >>> net.socket_create_filter = "disallow": no

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hi, On 2016년 12월 20일 04:47, Tobias Jakobi wrote: > Hello, > > I was just wondering what is improved by moving to regmap. For me this > looks like it only complicates the code. Lots of regmap_{read,write}() > and for each one of these we need to check the return code. It is correct to check the

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hi, On 2016년 12월 20일 04:47, Tobias Jakobi wrote: > Hello, > > I was just wondering what is improved by moving to regmap. For me this > looks like it only complicates the code. Lots of regmap_{read,write}() > and for each one of these we need to check the return code. It is correct to check the

[PATCH] rtlwifi: Fix kernel oops introduced with commit e49656147359

With commit e49656147359 {"rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb"), the method used to free an skb was changed because the kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb() guards against a NULL value for the argument. Routine dev_kfree_skb_irq() does not, and

[PATCH] rtlwifi: Fix kernel oops introduced with commit e49656147359

With commit e49656147359 {"rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb"), the method used to free an skb was changed because the kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb() guards against a NULL value for the argument. Routine dev_kfree_skb_irq() does not, and

Re: [PATCH] block: loose check on sg gap

On 12/19/2016 07:07 PM, Ming Lei wrote: > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe wrote: >> On 12/17/2016 03:49 AM, Ming Lei wrote: >>> If the last bvec of the 1st bio and the 1st bvec of the next >>> bio are contineous physically, and the latter can be merged >>> to last

Re: [PATCH] block: loose check on sg gap

On 12/19/2016 07:07 PM, Ming Lei wrote: > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe wrote: >> On 12/17/2016 03:49 AM, Ming Lei wrote: >>> If the last bvec of the 1st bio and the 1st bvec of the next >>> bio are contineous physically, and the latter can be merged >>> to last segment of the 1st

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Mon, 19 Dec 2016 16:20:05 -0800 Dave Hansen wrote: > On 12/19/2016 03:07 PM, Linus Torvalds wrote: > > +wait_queue_head_t *bit_waitqueue(void *word, int bit) > > +{ > > + const int __maybe_unused nid = page_to_nid(virt_to_page(word)); > > + >

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Mon, 19 Dec 2016 16:20:05 -0800 Dave Hansen wrote: > On 12/19/2016 03:07 PM, Linus Torvalds wrote: > > +wait_queue_head_t *bit_waitqueue(void *word, int bit) > > +{ > > + const int __maybe_unused nid = page_to_nid(virt_to_page(word)); > > + > > + return

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Mon, 19 Dec 2016 14:58:26 -0800 Dave Hansen wrote: > I saw a 4.8->4.9 regression (details below) that I attributed to: > > 9dcb8b685f mm: remove per-zone hashtable of bitlock waitqueues > > That commit took the bitlock waitqueues from being

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Mon, 19 Dec 2016 14:58:26 -0800 Dave Hansen wrote: > I saw a 4.8->4.9 regression (details below) that I attributed to: > > 9dcb8b685f mm: remove per-zone hashtable of bitlock waitqueues > > That commit took the bitlock waitqueues from being dynamically-allocated > per-zone to being

Re: [PATCH 4/4] oom-reaper: use madvise_dontneed() logic to decide if unmap the VMA

Hi Kirill, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/mm-drop-zap_details

Re: [PATCH 4/4] oom-reaper: use madvise_dontneed() logic to decide if unmap the VMA

Hi Kirill, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/mm-drop-zap_details

[PATCH 1/2] net: hix5hd2_gmac: fix compatible strings name

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name suffix "-gemac" is unnecessary. We also add another SoC compatible string in dt binding documentation

[PATCH 2/2] ARM: dts: hix5hd2: don't change the existing compatible string

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change it. We should only add the generic compatible string "hisi-gmac-v1". Fixes: 0855950ba580 ("ARM: dts: hix5hd2: add gmac generic compatible and clock names") Signed-off-by: Dongpo Li ---

[PATCH 1/2] net: hix5hd2_gmac: fix compatible strings name

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name suffix "-gemac" is unnecessary. We also add another SoC compatible string in dt binding documentation

[PATCH 2/2] ARM: dts: hix5hd2: don't change the existing compatible string

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change it. We should only add the generic compatible string "hisi-gmac-v1". Fixes: 0855950ba580 ("ARM: dts: hix5hd2: add gmac generic compatible and clock names") Signed-off-by: Dongpo Li ---

[PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed

This patch series fix the patch: d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string") The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name

[PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed

This patch series fix the patch: d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string") The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name

Re: OOM: Better, but still there on

On Mon, Dec 19, 2016 at 02:45:34PM +0100, Michal Hocko wrote: > Unfortunatelly shrink_active_list doesn't have any tracepoint so we do > not know whether we managed to rotate those pages. If they are referenced > quickly enough we might just keep refaulting them... Could you try to apply > the

Re: OOM: Better, but still there on

On Mon, Dec 19, 2016 at 02:45:34PM +0100, Michal Hocko wrote: > Unfortunatelly shrink_active_list doesn't have any tracepoint so we do > not know whether we managed to rotate those pages. If they are referenced > quickly enough we might just keep refaulting them... Could you try to apply > the

Re: [PATCH] block: loose check on sg gap

On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe wrote: > On 12/17/2016 03:49 AM, Ming Lei wrote: >> If the last bvec of the 1st bio and the 1st bvec of the next >> bio are contineous physically, and the latter can be merged >> to last segment of the 1st bio, we should think they don't

Re: [PATCH] block: loose check on sg gap

On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe wrote: > On 12/17/2016 03:49 AM, Ming Lei wrote: >> If the last bvec of the 1st bio and the 1st bvec of the next >> bio are contineous physically, and the latter can be merged >> to last segment of the 1st bio, we should think they don't >> violate sg

[PATCH] scsi: do not requeue requests unaligned with device sector size

When a SCSI command (e.g., read operation) is partially completed with good status and residual bytes (i.e., not all the bytes from the specified transfer length were transferred) the SCSI midlayer will update the request/bios with the completed bytes and requeue the request in order to complete

[PATCH] scsi: do not requeue requests unaligned with device sector size

When a SCSI command (e.g., read operation) is partially completed with good status and residual bytes (i.e., not all the bytes from the specified transfer length were transferred) the SCSI midlayer will update the request/bios with the completed bytes and requeue the request in order to complete

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: > On 12/19/16 5:25 PM, Andy Lutomirski wrote: >> net.socket_create_filter = "none": no filter >> net.socket_create_filter = "bpf:baadf00d": bpf filter >> net.socket_create_filter = "disallow": no sockets created period >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: > On 12/19/16 5:25 PM, Andy Lutomirski wrote: >> net.socket_create_filter = "none": no filter >> net.socket_create_filter = "bpf:baadf00d": bpf filter >> net.socket_create_filter = "disallow": no sockets created period >>

linux-next: Tree for Dec 20

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161219: The kvm tree lost its build failure. Non-merge commits (relative to Linus' tree): 566 1073 files changed, 26213 insertions(+), 8676 deletions

linux-next: Tree for Dec 20

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161219: The kvm tree lost its build failure. Non-merge commits (relative to Linus' tree): 566 1073 files changed, 26213 insertions(+), 8676 deletions

RE: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Tomas Henzl [mailto:the...@redhat.com] Sent: Thursday, December 15, 2016 10:10 AM To: Sasikumar PC; j...@kernel.org; h...@infradead.org Cc: linux-s...@vger.kernel.org; Sathya Prakash Veerichetty;

RE: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Tomas Henzl [mailto:the...@redhat.com] Sent: Thursday, December 15, 2016 10:10 AM To: Sasikumar PC; j...@kernel.org; h...@infradead.org Cc: linux-s...@vger.kernel.org; Sathya Prakash Veerichetty;

RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Sasikumar PC [mailto:sasikumar...@broadcom.com] Sent: Wednesday, December 14, 2016 4:49 PM To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org' Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash

RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Sasikumar PC [mailto:sasikumar...@broadcom.com] Sent: Wednesday, December 14, 2016 4:49 PM To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org' Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash

RE: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Sasikumar PC [mailto:sasikumar...@broadcom.com] Sent: Wednesday, December 14, 2016 4:43 PM To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org' Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash

RE: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

Hi Tomas, Please see my response inline Thanks sasi -Original Message- From: Sasikumar PC [mailto:sasikumar...@broadcom.com] Sent: Wednesday, December 14, 2016 4:43 PM To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org' Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash

Re: [kbuild-all] 答复： Re: [PATCH 1/2] ocfs2: add kobject for online file check

/Gang-He/ocfs2-add-kobject-for-online-file-check/20161219-181858 HEAD 6ef9256cd25ef72a5e69490cc3dacde95b8e2ac4 builds fine. It only hurts bisectibility. Thanks, Fengguang

Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Hi Brian, On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris wrote: > Hi Rajat, > > On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote: >> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that >> can be connected to a gpio on the CPU side, and can be

Re: [kbuild-all] 答复： Re: [PATCH 1/2] ocfs2: add kobject for online file check

/Gang-He/ocfs2-add-kobject-for-online-file-check/20161219-181858 HEAD 6ef9256cd25ef72a5e69490cc3dacde95b8e2ac4 builds fine. It only hurts bisectibility. Thanks, Fengguang

Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Hi Brian, On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris wrote: > Hi Rajat, > > On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote: >> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that >> can be connected to a gpio on the CPU side, and can be used to wakeup >> the host

Re: [PATCH 4/4] oom-reaper: use madvise_dontneed() logic to decide if unmap the VMA

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/mm-drop-zap_details

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 5:25 PM, Andy Lutomirski wrote: > net.socket_create_filter = "none": no filter > net.socket_create_filter = "bpf:baadf00d": bpf filter > net.socket_create_filter = "disallow": no sockets created period > net.socket_create_filter = "iptables:foobar": some iptables thingy >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm totally lost. Can you explain what this has to do with

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 5:25 PM, Andy Lutomirski wrote: > net.socket_create_filter = "none": no filter > net.socket_create_filter = "bpf:baadf00d": bpf filter > net.socket_create_filter = "disallow": no sockets created period > net.socket_create_filter = "iptables:foobar": some iptables thingy >

Re: [PATCH 4/4] oom-reaper: use madvise_dontneed() logic to decide if unmap the VMA

Hi Kirill, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/mm-drop-zap_details

答复： Re: [PATCH 1/2] ocfs2: add kobject for online file check

Hello Kbuild, Could you build my whole patch set (2 patch)? I think that the code is OK. Thanks Gang >>> kbuild test robot <l...@intel.com> 2016-12-19 下午 18:56 >>> Hi Gang, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161219] [

答复： Re: [PATCH 1/2] ocfs2: add kobject for online file check

Hello Kbuild, Could you build my whole patch set (2 patch)? I think that the code is OK. Thanks Gang >>> kbuild test robot 2016-12-19 下午 18:56 >>> Hi Gang, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161219] [if your patch is applied to

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:34 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 19 Dec 2016 16:02:56 -0800 > >> huh? 'not right api' because it's using bpf syscall instead >> of cgroup control-file? I think the opposite is the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:34 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 19 Dec 2016 16:02:56 -0800 > >> huh? 'not right api' because it's using bpf syscall instead >> of cgroup control-file? I think the opposite is the truth. > > I completely agree with Alexei on this. So

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 08:27 PM, Boris Ostrovsky wrote: On 12/19/2016 06:32 PM, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 07:43:40PM +0100, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: IIUIC find_microcode_in_initrd() is called with paging on only on

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 08:27 PM, Boris Ostrovsky wrote: On 12/19/2016 06:32 PM, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 07:43:40PM +0100, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: IIUIC find_microcode_in_initrd() is called with paging on only on

Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

On 2016/12/20 0:04, Rob Herring wrote: > On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li wrote: >> Hi Rob and David, >> >> On 2016/12/12 22:21, Rob Herring wrote: >>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li wrote: Hi Rob, On

Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

On 2016/12/20 0:04, Rob Herring wrote: > On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li wrote: >> Hi Rob and David, >> >> On 2016/12/12 22:21, Rob Herring wrote: >>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li wrote: Hi Rob, On 2016/12/10 6:35, Rob Herring wrote: > On Mon, Dec

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From: Alexei Starovoitov Date: Mon, 19 Dec 2016 16:02:56 -0800 > huh? 'not right api' because it's using bpf syscall instead > of cgroup control-file? I think the opposite is the truth. I completely agree with Alexei on this.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From: Alexei Starovoitov Date: Mon, 19 Dec 2016 16:02:56 -0800 > huh? 'not right api' because it's using bpf syscall instead > of cgroup control-file? I think the opposite is the truth. I completely agree with Alexei on this.

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 06:32 PM, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 07:43:40PM +0100, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: IIUIC find_microcode_in_initrd() is called with paging on only on Intel (which is where I observed it). Ah, that

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 06:32 PM, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 07:43:40PM +0100, Borislav Petkov wrote: On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: IIUIC find_microcode_in_initrd() is called with paging on only on Intel (which is where I observed it). Ah, that

Re: [PATCH] ALSA: snd-usb: fix IRQ triggered NULL pointer dereference

--- Hi, > Commit 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream") > fixes a race-codition but it also introduces another really nasty data race > regression which makes my usb sound card [1] completely useless, throwing > the kernel into a panic if anything from userspace tries

Re: [PATCH] ALSA: snd-usb: fix IRQ triggered NULL pointer dereference

--- Hi, > Commit 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream") > fixes a race-codition but it also introduces another really nasty data race > regression which makes my usb sound card [1] completely useless, throwing > the kernel into a panic if anything from userspace tries

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Dec 19, 2016 at 5:09 PM, Darrick J. Wong wrote: > On Mon, Dec 19, 2016 at 02:11:49PM -0700, Ross Zwisler wrote: >> On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote: >> <> >> > Definitely the first step would be your simple preallocated per >> >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Dec 19, 2016 at 5:09 PM, Darrick J. Wong wrote: > On Mon, Dec 19, 2016 at 02:11:49PM -0700, Ross Zwisler wrote: >> On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote: >> <> >> > Definitely the first step would be your simple preallocated per >> > inode approach until it is

Re: [PATCH] fbdev: remove current maintainer

Hi Daniel, On Thursday 08 Dec 2016 11:04:47 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:34:12AM +0200, Tomi Valkeinen wrote: > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. > > > > Signed-off-by: Tomi Valkeinen > > --- > > > > I just don't

Re: [PATCH] fbdev: remove current maintainer

Hi Daniel, On Thursday 08 Dec 2016 11:04:47 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:34:12AM +0200, Tomi Valkeinen wrote: > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. > > > > Signed-off-by: Tomi Valkeinen > > --- > > > > I just don't have time to even

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Dec 19, 2016 at 02:11:49PM -0700, Ross Zwisler wrote: > On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote: > <> > > Definitely the first step would be your simple preallocated per > > inode approach until it is shown to be insufficient. > > Reviving this thread a few months

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Dec 19, 2016 at 02:11:49PM -0700, Ross Zwisler wrote: > On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote: > <> > > Definitely the first step would be your simple preallocated per > > inode approach until it is shown to be insufficient. > > Reviving this thread a few months

Re: [PATCH] nvme-fabrics: remove some logically dead code performing redundant ret checks

Looks good. -- james Signed-off-by: James Smart On 12/9/2016 6:59 AM, Colin King wrote: From: Colin Ian King The check to see if ret is non-zero and return this rather than count is redundant in two occassions. It is redundant because

Re: [PATCH] nvme-fabrics: remove some logically dead code performing redundant ret checks

Looks good. -- james Signed-off-by: James Smart On 12/9/2016 6:59 AM, Colin King wrote: From: Colin Ian King The check to see if ret is non-zero and return this rather than count is redundant in two occassions. It is redundant because prior to this check, the return code ret is already

Re: [patch] nvme-fabrics: correct some printk information

Dan, Mind if I solve this a different way ? I really don't know why knowing the ptr value is even meaningful -- james On 12/10/2016 1:06 AM, Dan Carpenter wrote: We really don't care where "ctrl" is on the stack since we're just returning soon what we want is the actual ctrl pointer

Re: [patch] nvme-fabrics: correct some printk information

Dan, Mind if I solve this a different way ? I really don't know why knowing the ptr value is even meaningful -- james On 12/10/2016 1:06 AM, Dan Carpenter wrote: We really don't care where "ctrl" is on the stack since we're just returning soon what we want is the actual ctrl pointer

[PULL] One last documentation fix

The following changes since commit 3fa71d0f58a9b9df84e8e79196f961bcfbf01b2e: crypto: doc - optimize compilation (2016-12-13 16:38:07 -0700) are available in the git repository at: git://git.lwn.net/linux.git tags/doc-4.10-3 for you to fetch changes up to

[PULL] One last documentation fix

The following changes since commit 3fa71d0f58a9b9df84e8e79196f961bcfbf01b2e: crypto: doc - optimize compilation (2016-12-13 16:38:07 -0700) are available in the git repository at: git://git.lwn.net/linux.git tags/doc-4.10-3 for you to fetch changes up to

mmotm 2016-12-19-16-31 uploaded

The mm-of-the-moment snapshot 2016-12-19-16-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-12-19-16-31 uploaded

The mm-of-the-moment snapshot 2016-12-19-16-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH v2] fix code alignment with open parenthesis

On 12/19/2016 12:35 AM, Greg KH wrote: On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote: These changes where identified by checkpatch.pl as needed changes to align the code with the linux development coding style. The several lines of text where aligned with the precending

Re: [PATCH v2] fix code alignment with open parenthesis

On 12/19/2016 12:35 AM, Greg KH wrote: On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote: These changes where identified by checkpatch.pl as needed changes to align the code with the linux development coding style. The several lines of text where aligned with the precending

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov >> wrote: >> > On Sat, Dec 17, 2016 at 10:18:44AM

[PATCH] tty: hvc_dcc: Add basic early_con support

In some cases, earlycon can help catch errors with kernel boot prior to standard console is available. Example bootargs: console=hvc0 earlycon=hvcdcc Signed-off-by: Nishanth Menon <n...@ti.com> --- Based on: v4.9 tag Also applies on: next-20161219 Tested on Simulation environment (whi

[PATCH] tty: hvc_dcc: Add basic early_con support

In some cases, earlycon can help catch errors with kernel boot prior to standard console is available. Example bootargs: console=hvc0 earlycon=hvcdcc Signed-off-by: Nishanth Menon --- Based on: v4.9 tag Also applies on: next-20161219 Tested on Simulation environment (which did not have serial

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov >> wrote: >> > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: >> >> Hi all- >> >> >> >> I

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote: > 17.12.2016, 19:43, "Cihangir Akturk" : > > In the actual implementation ether_addr_equal function tests for equality > > to 0 > > when returning. It seems in commit 0d74c4 it is somehow overlooked to change > >

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote: > 17.12.2016, 19:43, "Cihangir Akturk" : > > In the actual implementation ether_addr_equal function tests for equality > > to 0 > > when returning. It seems in commit 0d74c4 it is somehow overlooked to change > > this operator to

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On 12/19/2016 03:07 PM, Linus Torvalds wrote: > +wait_queue_head_t *bit_waitqueue(void *word, int bit) > +{ > + const int __maybe_unused nid = page_to_nid(virt_to_page(word)); > + > + return __bit_waitqueue(word, bit, nid); > > No can do. Part of the problem with

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On 12/19/2016 03:07 PM, Linus Torvalds wrote: > +wait_queue_head_t *bit_waitqueue(void *word, int bit) > +{ > + const int __maybe_unused nid = page_to_nid(virt_to_page(word)); > + > + return __bit_waitqueue(word, bit, nid); > > No can do. Part of the problem with

Re: [PATCH 1/1] x86/platform/intel/quark: add printf attribute to imr_self_test_result()

On 19/12/16 13:21, Nicolas Iooss wrote: __printf attributes help detecting issues in printf format strings at compile time. Even though imr_selftest.c is only compiled with CONFIG_DEBUG_IMR_SELFTEST, gcc complains about a missing format attribute when compiling allmodconfig with

Re: [PATCH 1/1] x86/platform/intel/quark: add printf attribute to imr_self_test_result()

On 19/12/16 13:21, Nicolas Iooss wrote: __printf attributes help detecting issues in printf format strings at compile time. Even though imr_selftest.c is only compiled with CONFIG_DEBUG_IMR_SELFTEST, gcc complains about a missing format attribute when compiling allmodconfig with

[PATCH v2 0/1] perf: check that objdump correctly works

Hi Arnaldo, Here is a patch which checks that objdump works without calling it first with the "-v" option. Thanks to the shell pipefail option (which returns the rightmost error status in the shell pipe) and the grep subshell which prevents "no-match" errors, we are able the use waitpid on the

[PATCH v2 1/1] perf annotate: check that objdump correctly works

Before disassembling, the tool objdump is called just to be sure: * objdump is available in the path; * objdump is an executable binary; * objdump has no dependency issue or anything else. This objdump "pre-"command is only necessary because the real objdump command is followed by some " | grep

[PATCH v2 0/1] perf: check that objdump correctly works

Hi Arnaldo, Here is a patch which checks that objdump works without calling it first with the "-v" option. Thanks to the shell pipefail option (which returns the rightmost error status in the shell pipe) and the grep subshell which prevents "no-match" errors, we are able the use waitpid on the

[PATCH v2 1/1] perf annotate: check that objdump correctly works

Before disassembling, the tool objdump is called just to be sure: * objdump is available in the path; * objdump is an executable binary; * objdump has no dependency issue or anything else. This objdump "pre-"command is only necessary because the real objdump command is followed by some " | grep

Re: [PATCH v2] vfs: fix isize/pos/len checks for reflink & dedupe

On Mon, Dec 19, 2016 at 03:13:26PM -0800, Darrick J. Wong wrote: > Strengthen the checking of pos/len vs. i_size, clarify the return values > for the clone prep function, and remove pointless code. Applied.

Re: [PATCH v2] vfs: fix isize/pos/len checks for reflink & dedupe

On Mon, Dec 19, 2016 at 03:13:26PM -0800, Darrick J. Wong wrote: > Strengthen the checking of pos/len vs. i_size, clarify the return values > for the clone prep function, and remove pointless code. Applied.

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Pavel Machek : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Pavel Machek : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and we need a

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > wrote: > > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > >> Hi all- > >> > >> I apologize for being rather late with this.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > wrote: > > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > >> Hi all- > >> > >> I apologize for being rather late with this. I didn't realize that > >>

Re: [PATCH] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

On Mon, Dec 19, 2016 at 04:13:13PM -0700, Jonathan Corbet wrote: > On Mon, 19 Dec 2016 23:53:40 +0200 > Cihangir Akturk wrote: > > > In the actual implementation ether_addr_equal function tests for equality > > to 0 > > when returning. It seems in commit 0d74c4 it is somehow

Re: [PATCH] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

On Mon, Dec 19, 2016 at 04:13:13PM -0700, Jonathan Corbet wrote: > On Mon, 19 Dec 2016 23:53:40 +0200 > Cihangir Akturk wrote: > > > In the actual implementation ether_addr_equal function tests for equality > > to 0 > > when returning. It seems in commit 0d74c4 it is somehow overlooked to

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > wrote: > > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> >> > - if (shares < MIN_SHARES) > >> >> > - shares = MIN_SHARES; >

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > wrote: > > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> >> > - if (shares < MIN_SHARES) > >> >> > - shares = MIN_SHARES; > >> > ... > >> >> >

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