return USB_STOR_XFER_ERROR;
At a glance this seems odd to me. If the caller insists on ignoring
the return value, shouldn't it just initialize partial to zero?
In my experience it's generally frowned upon for functions to store
results in error paths.
Regards,
Vito Caputo
On Sat, Jul 25, 2020 at 04:11:58AM +0100, Matthew Wilcox wrote:
> On Fri, Jul 24, 2020 at 05:22:21PM -0700, Vito Caputo wrote:
> > Prior to looking at the code, conceptually I was envisioning the pages
> > in the reflink source inode's address_space would simply get their
>
cache utilization.
Dave did you ever end up going down this path?
Regards,
Vito Caputo
On Sun, Jul 05, 2020 at 01:44:54PM +0200, Greg KH wrote:
> On Sun, Jul 05, 2020 at 01:07:14AM -0700, Vito Caputo wrote:
> > On Sun, Jul 05, 2020 at 04:27:32AM +0100, Matthew Wilcox wrote:
> > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> > > > On Sun,
call to move the needle.
This syscall doesn't provide that. It doesn't really give any
advantage over what we can achieve already. It seems basically
pointless to me, from a monitoring proc files perspective.
Regards,
Vito Caputo
On Tue, May 12, 2020 at 03:44:08AM -0700, Vito Caputo wrote:
> On Tue, May 12, 2020 at 02:45:24AM -0700, Vito Caputo wrote:
> > Hello folks,
> >
> > I'm curious if someone knows a way to do this using existing linux
> > interfaces.
> >
> > I'd like to creat
On Tue, May 12, 2020 at 02:45:24AM -0700, Vito Caputo wrote:
> Hello folks,
>
> I'm curious if someone knows a way to do this using existing linux
> interfaces.
>
> I'd like to create a login lacking the ability to switch uid/gid.
>
> Even if the process has access to su
this on a specific user and all logins of that user are simply stuck
on that uid no matter what.
Thanks in advance,
Vito Caputo
:261
Signed-off-by: Vito Caputo
Reported-by: syzbot
---
drivers/media/usb/dvb-usb/cxusb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index f02fa0a67aa4..fac19ec46089 100644
--- a/drivers/media/usb
On Sun, Oct 13, 2019 at 01:17:18PM -0700, Eric Dumazet wrote:
>
>
> On 10/13/19 1:01 PM, Vito Caputo wrote:
> > On Sun, Oct 13, 2019 at 12:30:41PM -0700, Eric Dumazet wrote:
> >>
> >>
> >> On 10/12/19 4:55 AM, Vito Caputo wrote:
> >
On Sun, Oct 13, 2019 at 12:30:41PM -0700, Eric Dumazet wrote:
>
>
> On 10/12/19 4:55 AM, Vito Caputo wrote:
> > Eliminate some verbosity by using min() macro and consolidating some
> > things, also fix inconsistent zero tests (! vs. == 0).
> >
> > Signed-off-
Return directly from all switch cases, no point in storing in err.
Signed-off-by: Vito Caputo
---
net/core/skbuff.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f5f904f46893..c59b68a413b5 100644
--- a/net/core
Eliminate some verbosity by using min() macro and consolidating some
things, also fix inconsistent zero tests (! vs. == 0).
Signed-off-by: Vito Caputo
---
net/core/datagram.c | 44 ++--
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/net
Remove pointless use of size return variable by directly returning
sizes.
Signed-off-by: Vito Caputo
---
net/core/sock.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index fac2b4d80de5..e01ff0d3be95 100644
--- a/net/core/sock.c
Remove pointless return variable dance.
Appears vestigial from when the function did locking as seen in
unix_find_socket_byinode(), but locking is handled in
unix_find_socket_byname() for __unix_find_socket_byname().
Signed-off-by: Vito Caputo
---
net/unix/af_unix.c | 6 ++
1 file changed
Consolidate some duplicated bookkeeping from seq_read() into a
function.
Signed-off-by: Vito Caputo
---
fs/seq_file.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 1600034a929b..e5d2bccf5ac4 100644
the Xorg MIT cookie. This was shown in the strace log
> below:
>
> https://lkml.kernel.org/r/20190910173243.GA3992@darwi-home-pc
>
So did systemd-random-seed instead drain what little entropy there was
before GDM started, increasing the likelihood a subsequent getrandom()
call would block?
Regards,
Vito Caputo
in particular.
Regards,
Vito Caputo
located and empty
> openvt -c 40 -f -- true
>
> # open it and wait on read()
> cat /dev/tty40
>
> # from a second vt, simply open tty40 again
> true < /dev/tty40
>
> # come back to the first vt and watch cat bailing out with EAGAIN.
>
> Please fix.
>
>
>
On Thu, Jan 03, 2019 at 09:33:09PM +0100, Hussam Al-Tayeb wrote:
> > Sent: Thursday, January 03, 2019 at 10:12 PM
> > From: "Vito Caputo"
> > To: "Hussam Al-Tayeb"
> > Subject: Re: Excessive swapping under Linux 4.14.91 (no issues in 4.14.90).
>
since then (4.18 has some annoying i915 drm
bugs), and things have been perfectly fine in the storage/filesystem
department.
What I had noticed as being suspect back then was the following:
$ git tag --contains 744889b7cbb56a6
v4.19
v4.19.1
v4.19.2
v4.19.3
v4.19.4
v4.19.5
v4.20-rc1
v4.20-rc2
v4.20-rc3
v4.20-rc4
$ git tag --contains 1adfc5e4136f5967
v4.20-rc2
v4.20-rc3
v4.20-rc4
$
Since the 744889b7 commit message talks specifically about discard, and
1adfc5e4 claims to fix 744889b7, I assumed it was probably responsible
considering the tags profile, but did not try understand the commits or
bisect.
FYI the machine I observed this on is a SATA-attached SSD (Samsung 840
EVO 250G) X61s. I only run fstrim manually, but of course with discard
enabled all the way down the lvm+dmcrypt stack.
Maybe that's of use in hunting down this bug. If nobody else bisects in
the coming weeks I'll have to reconsider the rigamarole of backups,
repro, and attempting a bisect.
Regards,
Vito Caputo
since then (4.18 has some annoying i915 drm
bugs), and things have been perfectly fine in the storage/filesystem
department.
What I had noticed as being suspect back then was the following:
$ git tag --contains 744889b7cbb56a6
v4.19
v4.19.1
v4.19.2
v4.19.3
v4.19.4
v4.19.5
v4.20-rc1
v4.20-rc2
v4.20-rc3
v4.20-rc4
$ git tag --contains 1adfc5e4136f5967
v4.20-rc2
v4.20-rc3
v4.20-rc4
$
Since the 744889b7 commit message talks specifically about discard, and
1adfc5e4 claims to fix 744889b7, I assumed it was probably responsible
considering the tags profile, but did not try understand the commits or
bisect.
FYI the machine I observed this on is a SATA-attached SSD (Samsung 840
EVO 250G) X61s. I only run fstrim manually, but of course with discard
enabled all the way down the lvm+dmcrypt stack.
Maybe that's of use in hunting down this bug. If nobody else bisects in
the coming weeks I'll have to reconsider the rigamarole of backups,
repro, and attempting a bisect.
Regards,
Vito Caputo
4.3, that's left a
bad taste in my mouth but maybe I'm missing something.
Thanks,
Vito Caputo
4.3, that's left a
bad taste in my mouth but maybe I'm missing something.
Thanks,
Vito Caputo
ark abuse because MS is throwing money at them or is it a formal
licensing situation? Do we, the community, even have any right to know
what's going on?
Cheers,
Vito Caputo
ark abuse because MS is throwing money at them or is it a formal
licensing situation? Do we, the community, even have any right to know
what's going on?
Cheers,
Vito Caputo
sts. The more
differentials, the more fragmented the operation tended to be, requiring
increasing numbers of smaller reads across more files to reconstruct the
buffer.
The same thing would be useful for making reads from large numbers of
sysfs files less costly. I presume proposing such a generally
applicable VFS API addition would meet less resistance than specialized
proc interfaces, perhaps naively :).
Regards,
Vito Caputo
sts. The more
differentials, the more fragmented the operation tended to be, requiring
increasing numbers of smaller reads across more files to reconstruct the
buffer.
The same thing would be useful for making reads from large numbers of
sysfs files less costly. I presume proposing such a generally
applicable VFS API addition would meet less resistance than specialized
proc interfaces, perhaps naively :).
Regards,
Vito Caputo
On Tue, Oct 30, 2018 at 11:57:56AM -0700, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Vito Caputo wrote:
>
> > I'm definitely not in favor of just adding another stat file that is the
> > same format as the existing one with the intrs zeroed out. It's a dirty
> > h
On Tue, Oct 30, 2018 at 11:57:56AM -0700, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Vito Caputo wrote:
>
> > I'm definitely not in favor of just adding another stat file that is the
> > same format as the existing one with the intrs zeroed out. It's a dirty
> > h
expose in /proc,
while still being relatively efficient in terms of system calls per
sample. Sure you still have to lookup and open all the files of
interest, but that only needs to occur once at initialization.
Regards,
Vito Caputo
expose in /proc,
while still being relatively efficient in terms of system calls per
sample. Sure you still have to lookup and open all the files of
interest, but that only needs to occur once at initialization.
Regards,
Vito Caputo
On Mon, Oct 29, 2018 at 05:35:15PM -0400, Waiman Long wrote:
> On 10/29/2018 05:23 PM, Vito Caputo wrote:
> > On Mon, Oct 29, 2018 at 04:59:03PM -0400, Waiman Long wrote:
> >> On 10/29/2018 04:38 PM, Davidlohr Bueso wrote:
> >>> On Mon, 29 Oct 2018, Waiman Long wrot
On Mon, Oct 29, 2018 at 05:35:15PM -0400, Waiman Long wrote:
> On 10/29/2018 05:23 PM, Vito Caputo wrote:
> > On Mon, Oct 29, 2018 at 04:59:03PM -0400, Waiman Long wrote:
> >> On 10/29/2018 04:38 PM, Davidlohr Bueso wrote:
> >>> On Mon, 29 Oct 2018, Waiman Long wrot
ty to noop
fields before where I was polling proc frequently and skipping the bulk
of what was there but syscpu was still rather high.
I'm definitely not in favor of just adding another stat file that is the
same format as the existing one with the intrs zeroed out. It's a dirty
hack; fine for your local needs but too gross for upstream IMHO.
Regards,
Vito Caputo
ty to noop
fields before where I was polling proc frequently and skipping the bulk
of what was there but syscpu was still rather high.
I'm definitely not in favor of just adding another stat file that is the
same format as the existing one with the intrs zeroed out. It's a dirty
hack; fine for your local needs but too gross for upstream IMHO.
Regards,
Vito Caputo
On Tue, Oct 23, 2018 at 04:54:25AM +0100, Al Viro wrote:
> On Mon, Oct 22, 2018 at 08:47:19PM -0700, Vito Caputo wrote:
> > On Tue, Oct 23, 2018 at 04:38:52AM +0100, Al Viro wrote:
> > > On Mon, Oct 22, 2018 at 03:19:12AM -0700, Metztli Information Technology
> > >
On Tue, Oct 23, 2018 at 04:54:25AM +0100, Al Viro wrote:
> On Mon, Oct 22, 2018 at 08:47:19PM -0700, Vito Caputo wrote:
> > On Tue, Oct 23, 2018 at 04:38:52AM +0100, Al Viro wrote:
> > > On Mon, Oct 22, 2018 at 03:19:12AM -0700, Metztli Information Technology
> > >
thing similarly uncomfortable to explain to a
significant other as what you've been working on.
That is, assuming it's going to continue to exist in-tree...
Regards,
Vito Caputo
thing similarly uncomfortable to explain to a
significant other as what you've been working on.
That is, assuming it's going to continue to exist in-tree...
Regards,
Vito Caputo
ey want to throw some cheap storage at
enabling this coverage, or live with the existing risks.
I think it may be an interesting approach, enabling administrators to
repair primary storage while operating in a degraded mode. Then once
things are corrected, there would be a way to evict pages from
persistent swap for another shot at writeback to primary storage.
Regards,
Vito Caputo
ey want to throw some cheap storage at
enabling this coverage, or live with the existing risks.
I think it may be an interesting approach, enabling administrators to
repair primary storage while operating in a degraded mode. Then once
things are corrected, there would be a way to evict pages from
persistent swap for another shot at writeback to primary storage.
Regards,
Vito Caputo
On Mon, May 28, 2018 at 07:01:36PM +0200, Enric Balletbo Serra wrote:
> Hi Vito,
>
> cc: dm-devel, Alasdair and Mike Snitzer
>
> 2018-05-28 5:32 GMT+02:00 Vito Caputo :
> > On Thu, Jan 25, 2018 at 12:33:21AM -0800, vcap...@pengaru.com wrote:
> >> On Fri, Jan 19, 2
On Mon, May 28, 2018 at 07:01:36PM +0200, Enric Balletbo Serra wrote:
> Hi Vito,
>
> cc: dm-devel, Alasdair and Mike Snitzer
>
> 2018-05-28 5:32 GMT+02:00 Vito Caputo :
> > On Thu, Jan 25, 2018 at 12:33:21AM -0800, vcap...@pengaru.com wrote:
> >> On Fri, Jan 19, 2
half of
> > >> >> user processes in kworker threads to the work-causing process.
> > >> >>
> > >> >> What effectively happens is my normal `git` user process is able to
> > >> >> greatly amplify what share of CPU it takes fr
;> lacking
> > >> >> the appropriate mechanism for charging CPU resources consumed on
> > >> >> behalf of
> > >> >> user processes in kworker threads to the work-causing process.
> > >> >>
> > >> >> What effec
On Wed, May 23, 2018 at 03:27:34PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 03:27:34PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> > > >
On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> > > >
On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > >
On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > He
On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > He
On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > Hello all,
> >
> > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > without -window. I will try find time to build the
On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > Hello all,
> >
> > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > without -window. I will try find time to build the
On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> Hello all,
>
> 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> without -window. I will try find time to build the latest rc this
> evening.
>
> > ~$ xgalaga
> > X Error of fail
On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> Hello all,
>
> 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> without -window. I will try find time to build the latest rc this
> evening.
>
> > ~$ xgalaga
> > X Error of fail
venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
Regards,
Vito Caputo
4.17-rc4-config.gz
Description: application/gzip
venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
Regards,
Vito Caputo
4.17-rc4-config.gz
Description: application/gzip
---
Documentation/rbtree.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt
index c42a21b99046..3a4c23bc90b2 100644
--- a/Documentation/rbtree.txt
+++ b/Documentation/rbtree.txt
@@ -197,9 +197,9 @@ Cached rbtrees
---
Documentation/rbtree.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt
index c42a21b99046..3a4c23bc90b2 100644
--- a/Documentation/rbtree.txt
+++ b/Documentation/rbtree.txt
@@ -197,9 +197,9 @@ Cached rbtrees
Just something I noticed during my first 4.14 `make oldconfig`.
---
init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index 78cb2461012e..86dac3a573de 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1582,7 +1582,7 @@ config
Just something I noticed during my first 4.14 `make oldconfig`.
---
init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index 78cb2461012e..86dac3a573de 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1582,7 +1582,7 @@ config
NET_VENDOR_AQUANTIA was "default y" for some reason, which seems
obviously inappropriate.
---
drivers/net/ethernet/aquantia/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/Kconfig
b/drivers/net/ethernet/aquantia/Kconfig
index
NET_VENDOR_AQUANTIA was "default y" for some reason, which seems
obviously inappropriate.
---
drivers/net/ethernet/aquantia/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/Kconfig
b/drivers/net/ethernet/aquantia/Kconfig
index
()->iput_final(), which performs the shmem_unacct_size() for us.
Signed-off-by: Vito Caputo <vcap...@pengaru.com>
---
This caught my eye while looking through the memfd_create() implementation.
Included patch was compile tested only...
mm/shmem.c | 15 +--
1 file changed, 9 inserti
()->iput_final(), which performs the shmem_unacct_size() for us.
Signed-off-by: Vito Caputo
---
This caught my eye while looking through the memfd_create() implementation.
Included patch was compile tested only...
mm/shmem.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
d
72 matches
Mail list logo
