On (08/05/19 19:12), Al Viro wrote:
[..]
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
>
> Could you explain why the devil do you bother with remount at all?
I would redi
On 08/08/2019 17:23, Chris Wilson wrote:
Quoting Hugh Dickins (2019-08-08 16:54:16)
On Thu, 8 Aug 2019, Al Viro wrote:
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
Though personally I'm averse to managing "f"o
Quoting Hugh Dickins (2019-08-08 16:54:16)
> On Thu, 8 Aug 2019, Al Viro wrote:
> > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > > Though personally I'm averse to managing "f"objects through
> > > > "m"i
On Thu, 8 Aug 2019, Al Viro wrote:
> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > Though personally I'm averse to managing "f"objects through
> > > "m"interfaces, which can get ridiculous (notably, MADV_HU
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > Though personally I'm averse to managing "f"objects through
> > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > on the virtual address of
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> that mapping must have been decided previously). In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.
That'd be nice - we could kill the i915 wierd priva
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> Though personally I'm averse to managing "f"objects through
> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> on the virtual address of a mapping, but the huge-or-not alignment of
> that mapping must have been d
On Mon, 5 Aug 2019, Al Viro wrote:
> On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > > tmpfs does not set ->remount_fs() anymore and its users need
> > > to be converted to new mount API.
> >
> > Could you explain
On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
>
> Could you explain why the devil do you bother with remount at al
On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> tmpfs does not set ->remount_fs() anymore and its users need
> to be converted to new mount API.
Could you explain why the devil do you bother with remount at all?
Why not pass the right options when mounting the damn thing?
___
On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
>
> Could you explain why the devil do you bother with remount at al
tmpfs does not set ->remount_fs() anymore and its users need
to be converted to new mount API.
BUG: kernel NULL pointer dereference, address:
PF: supervisor instruction fetch in kernel mode
PF: error_code(0x0010) - not-present page
RIP: 0010:0x0
Code: Bad RIP value.
Call Tra
12 matches
Mail list logo
