Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Mon, Apr 24, 2017 at 9:15 PM, Matt Brown wrote: > This patchset introduces the tiocsti_restrict sysctl, whose default is > controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this > control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > > This

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Mon, Apr 24, 2017 at 9:15 PM, Matt Brown wrote: > This patchset introduces the tiocsti_restrict sysctl, whose default is > controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this > control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > > This patch was inspired

Re: [PATCH 1/9] Provide a function to create a NUL-terminated string from unterminated data

On Wed, May 03 2017, David Howells wrote: > Provide a function, kstrcreate() why not kmemdup_nul, since it seems to be to kmemdup exactly as memdup_user_nul is to memdup_user? Rasmus

Re: [PATCH 1/9] Provide a function to create a NUL-terminated string from unterminated data

On Wed, May 03 2017, David Howells wrote: > Provide a function, kstrcreate() why not kmemdup_nul, since it seems to be to kmemdup exactly as memdup_user_nul is to memdup_user? Rasmus

Re: [PATCH] ARM: Fix __show_regs output timestamps

On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote: > Multiple line formats are not preferred as the second and > subsequent lines may not have timestamps. > > Lacking timestamps makes reading the output a bit difficult. > This also makes arm/arm64 output more similar. > > Previous: >

Re: [PATCH] ARM: Fix __show_regs output timestamps

On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote: > Multiple line formats are not preferred as the second and > subsequent lines may not have timestamps. > > Lacking timestamps makes reading the output a bit difficult. > This also makes arm/arm64 output more similar. > > Previous: >

Re: [scsi-qedf] question about parameter ordering

Hi Chad, Quoting Chad Dupuis : On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1402011 I ran into the following piece of code at drivers/scsi/qedf/qedf_io.c:2057: /* Fill FC header */ fc_hdr =

Re: [scsi-qedf] question about parameter ordering

Hi Chad, Quoting Chad Dupuis : On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1402011 I ran into the following piece of code at drivers/scsi/qedf/qedf_io.c:2057: /* Fill FC header */ fc_hdr = &(tm_req->req_fc_hdr); sid =

Re: Asmedia USB 1343 crashes

On Wednesday, May 3, 2017 1:54:39 PM MDT Alan Stern wrote: > On Tue, 2 May 2017, Thomas Fjellstrom wrote: > > > I just had a brief lockup, desktop stopped responding, other usb devices > > not > > on the usb3 controller. Two android devices were in the process of > > restarting. > > > > It

Re: Asmedia USB 1343 crashes

On Wednesday, May 3, 2017 1:54:39 PM MDT Alan Stern wrote: > On Tue, 2 May 2017, Thomas Fjellstrom wrote: > > > I just had a brief lockup, desktop stopped responding, other usb devices > > not > > on the usb3 controller. Two android devices were in the process of > > restarting. > > > > It

[PATCH] scsi: qedf: properly update arguments position in function call

Properly update the position of the arguments in function call. Addresses-Coverity-ID: 1402010 Signed-off-by: Gustavo A. R. Silva --- drivers/scsi/qedf/qedf_els.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedf/qedf_els.c

[PATCH] scsi: qedf: properly update arguments position in function call

Properly update the position of the arguments in function call. Addresses-Coverity-ID: 1402010 Signed-off-by: Gustavo A. R. Silva --- drivers/scsi/qedf/qedf_els.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedf/qedf_els.c b/drivers/scsi/qedf/qedf_els.c

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

On Wed, May 3, 2017 at 10:06 PM, Greg Kroah-Hartman wrote: > On Wed, May 03, 2017 at 09:13:51PM +0300, Andy Shevchenko wrote: >> +Cc: Petr >> >> On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre >> wrote: >> > All the console driver handling

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

On Wed, May 3, 2017 at 10:06 PM, Greg Kroah-Hartman wrote: > On Wed, May 03, 2017 at 09:13:51PM +0300, Andy Shevchenko wrote: >> +Cc: Petr >> >> On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre >> wrote: >> > All the console driver handling code lives in printk.c. >> > Move console_init() there

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

On Wed, May 03, 2017 at 09:13:51PM +0300, Andy Shevchenko wrote: > +Cc: Petr > > On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre > wrote: > > All the console driver handling code lives in printk.c. > > Move console_init() there as well so console support can still be

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

On Wed, May 03, 2017 at 09:13:51PM +0300, Andy Shevchenko wrote: > +Cc: Petr > > On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre > wrote: > > All the console driver handling code lives in printk.c. > > Move console_init() there as well so console support can still be used > > when the TTY code

Re: [PATCH v4 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

Daniel Vetter writes: > On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote: >> The FBDEV initialization would throw an error in dmesg, when we just >> want to silently not initialize fbdev on a V3D-only VC4 instance. >> >> Signed-off-by: Eric Anholt >

Re: [PATCH v4 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

Daniel Vetter writes: > On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote: >> The FBDEV initialization would throw an error in dmesg, when we just >> want to silently not initialize fbdev on a V3D-only VC4 instance. >> >> Signed-off-by: Eric Anholt > > With the commit message updated

Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote: > >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format > >*fmt) > >+{ > >+long long avg_lum = 0; > >+int x, y; > >+ > >+buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + > >+

Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote: > >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format > >*fmt) > >+{ > >+long long avg_lum = 0; > >+int x, y; > >+ > >+buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + > >+

Re: RFC: i2c designware gpio recovery

Good Day Phil Am Mittwoch, 3. Mai 2017, 09:30:50 CEST schrieb Phil Reid: > G'day Tim, > > On 1/05/2017 21:31, Tim Sander wrote: > > Good Day Phil > > > > Am Montag, 1. Mai 2017, 09:57:35 CEST schrieb Phil Reid: > >>> So i took a look into the device tree file socfpga.dtsi and found that > >>>

Re: RFC: i2c designware gpio recovery

Good Day Phil Am Mittwoch, 3. Mai 2017, 09:30:50 CEST schrieb Phil Reid: > G'day Tim, > > On 1/05/2017 21:31, Tim Sander wrote: > > Good Day Phil > > > > Am Montag, 1. Mai 2017, 09:57:35 CEST schrieb Phil Reid: > >>> So i took a look into the device tree file socfpga.dtsi and found that > >>>

Re: [PATCH RFC] hugetlbfs 'noautofill' mount option

On 5/2/17 4:43 PM, Dave Hansen wrote: On 05/02/2017 04:34 PM, Prakash Sangappa wrote: Similarly, a madvise() option also requires additional system call by every process mapping the file, this is considered a overhead for the database. How long-lived are these processes? For a database, I'd

Re: [PATCH RFC] hugetlbfs 'noautofill' mount option

On 5/2/17 4:43 PM, Dave Hansen wrote: On 05/02/2017 04:34 PM, Prakash Sangappa wrote: Similarly, a madvise() option also requires additional system call by every process mapping the file, this is considered a overhead for the database. How long-lived are these processes? For a database, I'd

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 3-1-2017 18:59, Luis R. Rodriguez wrote: > On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote: >> >> Right question is "should we solve it without user-space help"? >> >> Answer is no, too. Way too complex. Yes, it would be nice if hardware >> was designed in such a way that getting

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 3-1-2017 18:59, Luis R. Rodriguez wrote: > On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote: >> >> Right question is "should we solve it without user-space help"? >> >> Answer is no, too. Way too complex. Yes, it would be nice if hardware >> was designed in such a way that getting

Re: [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy

On Mon, Apr 10, 2017 at 09:52:47AM -0500, Dave Gerlach wrote: > Currently the sram-exec functionality, which allows allocation of > executable memory and provides an API to move code to it, is only > selected in configs for the ARM architecture. Based on commit > 5756e9dd0de6 ("ARM: 6640/1:

Re: [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy

On Mon, Apr 10, 2017 at 09:52:47AM -0500, Dave Gerlach wrote: > Currently the sram-exec functionality, which allows allocation of > executable memory and provides an API to move code to it, is only > selected in configs for the ARM architecture. Based on commit > 5756e9dd0de6 ("ARM: 6640/1:

Re: [PATCH] clk: Add functions to save and restore clock/dpll context en-masse

On Tue, Apr 18, 2017 at 10:42:49AM +0530, Keerthy wrote: > From: Russ Dill > > The clock/dpll registers are in the WKUP power domain. Under both RTC-only > suspend and hibernation, these registers are lost. Hence save/restore > them accordingly. This looks like a huge hammer,

Re: [PATCH] clk: Add functions to save and restore clock/dpll context en-masse

On Tue, Apr 18, 2017 at 10:42:49AM +0530, Keerthy wrote: > From: Russ Dill > > The clock/dpll registers are in the WKUP power domain. Under both RTC-only > suspend and hibernation, these registers are lost. Hence save/restore > them accordingly. This looks like a huge hammer, and I think this

[PATCH V3 linux-next] nfs: use kmap/kunmap directly

This patch removes useless nfs_readdir_get_array() and nfs_readdir_release_array() as suggested by Trond Myklebust nfs_readdir() calls nfs_revalidate_mapping() before readdir_search_pagecache() , nfs_do_filldir(), uncached_readdir() so mapping should be correct. While kmap() can't fail, all

[PATCH V3 linux-next] nfs: use kmap/kunmap directly

This patch removes useless nfs_readdir_get_array() and nfs_readdir_release_array() as suggested by Trond Myklebust nfs_readdir() calls nfs_revalidate_mapping() before readdir_search_pagecache() , nfs_do_filldir(), uncached_readdir() so mapping should be correct. While kmap() can't fail, all

[git pull] Input updates for v4.11-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a big update from Mauro converting input documentation to ReST format - Synaptics PS/2 is now aware of SMBus companion

[git pull] Input updates for v4.11-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a big update from Mauro converting input documentation to ReST format - Synaptics PS/2 is now aware of SMBus companion

Re: [scsi-qedf] question about parameter ordering

On Wed, 3 May 2017, 2:36pm, Randy Dunlap wrote: > On 05/03/17 11:29, Chad Dupuis wrote: > > > > On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > > > >> > >> Hello everybody, > >> > >> While looking into Coverity ID 1402011 I ran into the following piece of > >> code > >> at

Re: [scsi-qedf] question about parameter ordering

On Wed, 3 May 2017, 2:36pm, Randy Dunlap wrote: > On 05/03/17 11:29, Chad Dupuis wrote: > > > > On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > > > >> > >> Hello everybody, > >> > >> While looking into Coverity ID 1402011 I ran into the following piece of > >> code > >> at

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On 05/03/2017 02:19 PM, David Woodhouse wrote: > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: >> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: >>> On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: On 02/21/2017 10:45 AM, Juergen Gross wrote: > On 21/02/17 16:31,

Re: [PATCH 3/3] f2fs: enhance scalability of trace macro

Hi Chao, On 05/03, Chao Yu wrote: > From: Chao Yu > > Use __print_flags in show_bio_op_flags and show_cpreason instead of > __print_symbolic, it enables tracer function traverses and shows all > bits in the flag. > > Additionally, add missing REQ_FUA into F2FS_OP_FLAGS. >

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On 05/03/2017 02:19 PM, David Woodhouse wrote: > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: >> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: >>> On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: On 02/21/2017 10:45 AM, Juergen Gross wrote: > On 21/02/17 16:31,

Re: [PATCH 3/3] f2fs: enhance scalability of trace macro

Hi Chao, On 05/03, Chao Yu wrote: > From: Chao Yu > > Use __print_flags in show_bio_op_flags and show_cpreason instead of > __print_symbolic, it enables tracer function traverses and shows all > bits in the flag. > > Additionally, add missing REQ_FUA into F2FS_OP_FLAGS. > > Signed-off-by:

Клиентские базы http://xurl.es/PR0DAWEZ для Малого Бизнеса!

Клиентские базы http://xurl.es/PR0DAWEZ для Малого Бизнеса!

Клиентские базы http://xurl.es/PR0DAWEZ для Малого Бизнеса!

Клиентские базы http://xurl.es/PR0DAWEZ для Малого Бизнеса!

Re: [RFC PATCH] dax: add badblocks check to Device DAX

On Wed, 2017-05-03 at 09:30 -0700, Dan Williams wrote: > On Wed, May 3, 2017 at 9:09 AM, Kani, Toshimitsu > wrote: > > On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote: > > > On Wed, May 3, 2017 at 8:31 AM, Toshi Kani > > > wrote: > > > > This is a

Re: [RFC PATCH] dax: add badblocks check to Device DAX

On Wed, 2017-05-03 at 09:30 -0700, Dan Williams wrote: > On Wed, May 3, 2017 at 9:09 AM, Kani, Toshimitsu > wrote: > > On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote: > > > On Wed, May 3, 2017 at 8:31 AM, Toshi Kani > > > wrote: > > > > This is a RFC patch for seeking suggestions.  It

Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem

On Tue, 2017-05-02 at 13:54 -0700, David Rientjes wrote: > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c > > index 7e4a9d1..3a765e02 100644 > > --- a/drivers/char/mem.c > > +++ b/drivers/char/mem.c > > @@ -55,7 +55,7 @@ static inline int > valid_phys_addr_range(phys_addr_t addr, size_t

Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem

On Tue, 2017-05-02 at 13:54 -0700, David Rientjes wrote: > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c > > index 7e4a9d1..3a765e02 100644 > > --- a/drivers/char/mem.c > > +++ b/drivers/char/mem.c > > @@ -55,7 +55,7 @@ static inline int > valid_phys_addr_range(phys_addr_t addr, size_t

[patch 3/3] MM: allow per-cpu vmstat_worker configuration

Following the reasoning on the last patch in the series, this patch allows configuration of the per-CPU vmstat worker: it allows the user to disable the per-CPU vmstat worker. Signed-off-by: Marcelo Tosatti --- linux/mm/vmstat.c.sothresh 2017-05-03 11:01:17.465914562 -0300

[patch 0/3] per-CPU vmstat thresholds and vmstat worker disablement (v2)

The per-CPU vmstat worker is a problem on -RT workloads (because ideally the CPU is entirely reserved for the -RT app, without interference). The worker transfers accumulated per-CPU vmstat counters to global counters. To resolve the problem, create two tunables: * Userspace configurable per-CPU

[patch 3/3] MM: allow per-cpu vmstat_worker configuration

Following the reasoning on the last patch in the series, this patch allows configuration of the per-CPU vmstat worker: it allows the user to disable the per-CPU vmstat worker. Signed-off-by: Marcelo Tosatti --- linux/mm/vmstat.c.sothresh 2017-05-03 11:01:17.465914562 -0300 +++

[patch 0/3] per-CPU vmstat thresholds and vmstat worker disablement (v2)

The per-CPU vmstat worker is a problem on -RT workloads (because ideally the CPU is entirely reserved for the -RT app, without interference). The worker transfers accumulated per-CPU vmstat counters to global counters. To resolve the problem, create two tunables: * Userspace configurable per-CPU

[patch 1/3] MM: remove unused quiet_vmstat function

Remove unused quiet_vmstat function. Signed-off-by: Marcelo Tosatti --- include/linux/vmstat.h |1 - mm/vmstat.c| 25 - 2 files changed, 26 deletions(-) Index: linux-2.6-git-disable-vmstat-worker/include/linux/vmstat.h

[patch 1/3] MM: remove unused quiet_vmstat function

Remove unused quiet_vmstat function. Signed-off-by: Marcelo Tosatti --- include/linux/vmstat.h |1 - mm/vmstat.c| 25 - 2 files changed, 26 deletions(-) Index: linux-2.6-git-disable-vmstat-worker/include/linux/vmstat.h

[patch 2/3] MM: allow per-cpu vmstat_threshold configuration

The per-CPU vmstat worker is a problem on -RT workloads (because ideally the CPU is entirely reserved for the -RT app, without interference). The worker transfers accumulated per-CPU vmstat counters to global counters. To resolve the problem, create a userspace configurable per-CPU vmstat

[patch 2/3] MM: allow per-cpu vmstat_threshold configuration

The per-CPU vmstat worker is a problem on -RT workloads (because ideally the CPU is entirely reserved for the -RT app, without interference). The worker transfers accumulated per-CPU vmstat counters to global counters. To resolve the problem, create a userspace configurable per-CPU vmstat

Re: [PATCH] brd: fix uninitialized use of brd->dax_dev

On Wed, May 3, 2017 at 5:56 AM, Gerald Schaefer wrote: > commit 1647b9b9 "brd: add dax_operations support" introduced the allocation > and freeing of a dax_device, but the allocated dax_device is not stored > into the brd_device, so brd_del_one() will eventually

Re: [PATCH] brd: fix uninitialized use of brd->dax_dev

On Wed, May 3, 2017 at 5:56 AM, Gerald Schaefer wrote: > commit 1647b9b9 "brd: add dax_operations support" introduced the allocation > and freeing of a dax_device, but the allocated dax_device is not stored > into the brd_device, so brd_del_one() will eventually operate on an > uninitialized

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 19:37 +0100, David Howells wrote: > Joe Perches wrote: > > > krealloc would probably be more efficient and possible > > readable as likely there's already padding in the original > > allocation. > > The problem is if krealloc() fails: you've lost all

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 19:37 +0100, David Howells wrote: > Joe Perches wrote: > > > krealloc would probably be more efficient and possible > > readable as likely there's already padding in the original > > allocation. > > The problem is if krealloc() fails: you've lost all those pointers to

Re: `pci_apply_final_quirks()` taking half a second

On Sat, Apr 8, 2017 at 10:06 PM, Bjorn Helgaas wrote: > On Sat, Apr 08, 2017 at 07:00:19PM +0200, David Woodhouse wrote: >> ... >> I note it's also reading PCI_CACHE_LINE_SIZE From config space for each >> device in pci_apply_final_quirks(). How long does that take? > > I

Re: `pci_apply_final_quirks()` taking half a second

On Sat, Apr 8, 2017 at 10:06 PM, Bjorn Helgaas wrote: > On Sat, Apr 08, 2017 at 07:00:19PM +0200, David Woodhouse wrote: >> ... >> I note it's also reading PCI_CACHE_LINE_SIZE From config space for each >> device in pci_apply_final_quirks(). How long does that take? > > I don't know, but it's

Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

Jeff Layton wrote: > I think one of the neat things here is that we can now error out as > soon as a bogus mount option is passed in. It means that the 'sloppy' option can also now be implemented in userspace. > > Once fsmount() has been called, further write() calls

Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

Jeff Layton wrote: > I think one of the neat things here is that we can now error out as > soon as a bogus mount option is passed in. It means that the 'sloppy' option can also now be implemented in userspace. > > Once fsmount() has been called, further write() calls will incur EBUSY, > > even

Re: [GIT PULL] MD update for 4.12

On Wed, May 03, 2017 at 10:27:47AM -0700, Linus Torvalds wrote: > On Mon, May 1, 2017 at 3:50 PM, Shaohua Li wrote: > > > > Please pull MD update for 4.12. There are conflicts between MD tree and > > block > > tree, so I did a merge before the pull request. > > I pulled this,

Re: [GIT PULL] MD update for 4.12

On Wed, May 03, 2017 at 10:27:47AM -0700, Linus Torvalds wrote: > On Mon, May 1, 2017 at 3:50 PM, Shaohua Li wrote: > > > > Please pull MD update for 4.12. There are conflicts between MD tree and > > block > > tree, so I did a merge before the pull request. > > I pulled this, but *please* don't

Re: [PATCH 3/9] VFS: Introduce a mount context

Joe Perches wrote: > krealloc would probably be more efficient and possible > readable as likely there's already padding in the original > allocation. The problem is if krealloc() fails: you've lost all those pointers to things you then need to free. > Are there no locking

Re: [PATCH 3/9] VFS: Introduce a mount context

Joe Perches wrote: > krealloc would probably be more efficient and possible > readable as likely there's already padding in the original > allocation. The problem is if krealloc() fails: you've lost all those pointers to things you then need to free. > Are there no locking constraints?

Re: [scsi-qedf] question about parameter ordering

On 05/03/17 11:29, Chad Dupuis wrote: > > On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > >> >> Hello everybody, >> >> While looking into Coverity ID 1402011 I ran into the following piece of code >> at drivers/scsi/qedf/qedf_io.c:2057: >> >> /* Fill FC header */ >> fc_hdr =

Re: [scsi-qedf] question about parameter ordering

On 05/03/17 11:29, Chad Dupuis wrote: > > On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > >> >> Hello everybody, >> >> While looking into Coverity ID 1402011 I ran into the following piece of code >> at drivers/scsi/qedf/qedf_io.c:2057: >> >> /* Fill FC header */ >> fc_hdr =

Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

On Wed, 2017-05-03 at 17:05 +0100, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char *fsname, int

Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

On Wed, 2017-05-03 at 17:05 +0100, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char *fsname, int

[PATCH 2/2] blk-mq-debugfs: Add spaces in queue_poll_stat_show()

From: Markus Elfring Date: Wed, 3 May 2017 20:18:22 +0200 Use space characters at some source code places according to the Linux coding style convention. Signed-off-by: Markus Elfring --- block/blk-mq-debugfs.c | 10 +- 1

[PATCH 2/2] blk-mq-debugfs: Add spaces in queue_poll_stat_show()

From: Markus Elfring Date: Wed, 3 May 2017 20:18:22 +0200 Use space characters at some source code places according to the Linux coding style convention. Signed-off-by: Markus Elfring --- block/blk-mq-debugfs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH 1/2] blk-mq-debugfs: Replace seven seq_puts() calls by seq_putc()

From: Markus Elfring Date: Wed, 3 May 2017 20:00:49 +0200 A few single characters should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 1/2] blk-mq-debugfs: Replace seven seq_puts() calls by seq_putc()

From: Markus Elfring Date: Wed, 3 May 2017 20:00:49 +0200 A few single characters should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- block/blk-mq-debugfs.c | 15

[PATCH 0/2] blk-mq-debugfs: Fine-tuning for five function implementations

From: Markus Elfring Date: Wed, 3 May 2017 20:30:40 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Replace seven seq_puts() calls by seq_putc() Add spaces in queue_poll_stat_show()

[PATCH 0/2] blk-mq-debugfs: Fine-tuning for five function implementations

From: Markus Elfring Date: Wed, 3 May 2017 20:30:40 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Replace seven seq_puts() calls by seq_putc() Add spaces in queue_poll_stat_show() block/blk-mq-debugfs.c | 25

Re: [scsi-qedf] question about parameter ordering

On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1402011 I ran into the following piece of code > at drivers/scsi/qedf/qedf_io.c:2057: > > /* Fill FC header */ > fc_hdr = &(tm_req->req_fc_hdr); > sid = fcport->sid; > did =

Re: [scsi-qedf] question about parameter ordering

On Wed, 3 May 2017, 1:58pm, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1402011 I ran into the following piece of code > at drivers/scsi/qedf/qedf_io.c:2057: > > /* Fill FC header */ > fc_hdr = &(tm_req->req_fc_hdr); > sid = fcport->sid; > did =

[PATCH 2/2 linux-next] gfs2: remove unused flags parameter

We already assumed rename flags when calling gfs2_exchange() Signed-off-by: Fabian Frederick --- fs/gfs2/inode.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index 9698796..b5858a3 100644 --- a/fs/gfs2/inode.c +++

[PATCH 2/2 linux-next] gfs2: remove unused flags parameter

We already assumed rename flags when calling gfs2_exchange() Signed-off-by: Fabian Frederick --- fs/gfs2/inode.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index 9698796..b5858a3 100644 --- a/fs/gfs2/inode.c +++ b/fs/gfs2/inode.c

[PATCH 1/2 linux-next] gfs2: check rename2 flags at once

There's no need to update flags in gfs2_rename2() This will ease whiteout addition. Signed-off-by: Fabian Frederick --- fs/gfs2/inode.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index 9f605ea..9698796 100644 ---

[PATCH 1/2 linux-next] gfs2: check rename2 flags at once

There's no need to update flags in gfs2_rename2() This will ease whiteout addition. Signed-off-by: Fabian Frederick --- fs/gfs2/inode.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index 9f605ea..9698796 100644 --- a/fs/gfs2/inode.c

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote: > On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote: > > Introduce a mount context concept. trivia: > > static int selinux_mount_ctx_option(struct mount_context *mc, char *opt) > > +{ [] > > + if (opts->mnt_opts) { > > + oo =

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote: > On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote: > > Introduce a mount context concept. trivia: > > static int selinux_mount_ctx_option(struct mount_context *mc, char *opt) > > +{ [] > > + if (opts->mnt_opts) { > > + oo =

Re: [PATCH] sd: Ignore sync cache failures when not supported

On Thu, 2017-03-16 at 17:48 +0100, Thierry Escande wrote: > -static int sd_sync_cache(struct scsi_disk *sdkp) > +static int sd_sync_cache(struct scsi_disk *sdkp, int *sense_key) > { > int retries, res; > struct scsi_device *sdp = sdkp->device; Hello Thierry, Both in the SCSI spec

Re: [PATCH] sd: Ignore sync cache failures when not supported

On Thu, 2017-03-16 at 17:48 +0100, Thierry Escande wrote: > -static int sd_sync_cache(struct scsi_disk *sdkp) > +static int sd_sync_cache(struct scsi_disk *sdkp, int *sense_key) > { > int retries, res; > struct scsi_device *sdp = sdkp->device; Hello Thierry, Both in the SCSI spec

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 11:02 AM, Cong Wang wrote: > A quick glance shows we need to simply check local->rt6i_idev > since we do the same check for sprt right above. As I recall, rt6i_idev is set for all routes except null_entry and it is not set on null_entry only because of initialization order. > > diff

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 11:02 AM, Cong Wang wrote: > A quick glance shows we need to simply check local->rt6i_idev > since we do the same check for sprt right above. As I recall, rt6i_idev is set for all routes except null_entry and it is not set on null_entry only because of initialization order. > > diff

Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

On Mon, 24 Apr 2017, NeilBrown wrote: > On Fri, Apr 21 2017, Mikulas Patocka wrote: > > > On Mon, 10 Apr 2017, NeilBrown wrote: > > > >> mempool_alloc() should only be called with GFP_ATOMIC when > >> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc() > >> says that it is safe to wait

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: > > > > On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: > > > > > > On 02/21/2017 10:45 AM, Juergen Gross wrote: > > > > > > > > On 21/02/17 16:31, Dan Streetman wrote: > >

Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

On Mon, 24 Apr 2017, NeilBrown wrote: > On Fri, Apr 21 2017, Mikulas Patocka wrote: > > > On Mon, 10 Apr 2017, NeilBrown wrote: > > > >> mempool_alloc() should only be called with GFP_ATOMIC when > >> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc() > >> says that it is safe to wait

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: > > > > On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: > > > > > > On 02/21/2017 10:45 AM, Juergen Gross wrote: > > > > > > > > On 21/02/17 16:31, Dan Streetman wrote: > >

Re: [PATCH RFC] scsi: wait sd probing in manual scan

On Fri, 2017-04-28 at 15:48 +0800, Peng Tao wrote: > We have a guest init programe trying to mount a device after doing scsi host > scan > at boot time. Occasionally it fails to find the device when mounting. After > digging > a bit, it seems the root cause is sd async_schedule probing. > >

Re: [PATCH RFC] scsi: wait sd probing in manual scan

On Fri, 2017-04-28 at 15:48 +0800, Peng Tao wrote: > We have a guest init programe trying to mount a device after doing scsi host > scan > at boot time. Occasionally it fails to find the device when mounting. After > digging > a bit, it seems the root cause is sd async_schedule probing. > >

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote: > Introduce a mount context concept. This is allocated at the beginning of > the mount procedure and into it is placed: > > (1) Filesystem type. > > (2) Namespaces. > > (3) Device name. > > (4) Superblock flags (MS_*) and mount flags

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote: > Introduce a mount context concept. This is allocated at the beginning of > the mount procedure and into it is placed: > > (1) Filesystem type. > > (2) Namespaces. > > (3) Device name. > > (4) Superblock flags (MS_*) and mount flags

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

+Cc: Petr On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre wrote: > All the console driver handling code lives in printk.c. > Move console_init() there as well so console support can still be used > when the TTY code is configured out. No logical changes from this patch.

Re: [PATCH 1/4] console: move console_init() out of tty_io.c

+Cc: Petr On Thu, Apr 13, 2017 at 1:37 AM, Nicolas Pitre wrote: > All the console driver handling code lives in printk.c. > Move console_init() there as well so console support can still be used > when the TTY code is configured out. No logical changes from this patch. > So, I missed cover

Re: [PATCH] tty: serdev: fix serdev_device_write return value

On Wed, May 03, 2017 at 08:44:07PM +0300, Andy Shevchenko wrote: > On Tue, May 2, 2017 at 12:25 PM, Johan Hovold wrote: > > On Mon, May 01, 2017 at 07:17:14PM -0500, Rob Herring wrote: > > >> - return ret < 0 ? ret : (count ? -ETIMEDOUT : 0); > >> + return ret < 0 ? ret

Re: [PATCH] tty: serdev: fix serdev_device_write return value

On Wed, May 03, 2017 at 08:44:07PM +0300, Andy Shevchenko wrote: > On Tue, May 2, 2017 at 12:25 PM, Johan Hovold wrote: > > On Mon, May 01, 2017 at 07:17:14PM -0500, Rob Herring wrote: > > >> - return ret < 0 ? ret : (count ? -ETIMEDOUT : 0); > >> + return ret < 0 ? ret : (count ?

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