On Sat, Aug 31, 2019 at 04:44:48PM +0200, Christoph Hellwig wrote:
> On Sat, Aug 31, 2019 at 02:35:37PM +0100, Al Viro wrote:
> > > So for the one real life example of the configfs attribute life
> > > actually is simpler. acpi_table_aml_write verifies early on that
> > > the size matches what it
On Sat, Aug 31, 2019 at 02:35:37PM +0100, Al Viro wrote:
> > So for the one real life example of the configfs attribute life
> > actually is simpler. acpi_table_aml_write verifies early on that
> > the size matches what it expects. So if we document that any future
> > instance needs to be able t
On Sat, Aug 31, 2019 at 10:32:41AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 26, 2019 at 08:28:19PM +0100, Al Viro wrote:
> > For configfs bin_attr it won't work, simply because it wants the entire
> > thing to be present - callback parses the data. For SCSI tape... Maybe,
> > but you'll need
On Mon, Aug 26, 2019 at 08:28:19PM +0100, Al Viro wrote:
> For configfs bin_attr it won't work, simply because it wants the entire
> thing to be present - callback parses the data. For SCSI tape... Maybe,
> but you'll need to take care of the overlaps with ->write(). Right now
> it can't happen
On Fri, Aug 30, 2019 at 05:44:39AM +0100, Al Viro wrote:
> > Not quite right. XFS only returns an error if there is data
> > writeback failure or filesystem corruption or shutdown detected
> > during whatever operation it is performing.
> >
> > We don't really care what is done with the error that
On Fri, Aug 30, 2019 at 02:10:42PM +1000, Dave Chinner wrote:
> > reiserfs_file_release():
> > tries to return an error if it can't free preallocated blocks.
> >
> > xfs_release():
> > similar to the previous case.
>
> Not quite right. XFS only returns an error if there is data
> writeba
On Thu, Aug 29, 2019 at 11:22:58PM +0100, Al Viro wrote:
> On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote:
>
> > Most of them are actually pure bollocks - "it can never happen, but if it
> > does,
> > let's return -EWHATEVER to feel better". Some are crap like -EINTR, which
> > is
> >
On Thu, Aug 29, 2019 at 11:22:58PM +0100, Al Viro wrote:
> On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote:
>
> > Most of them are actually pure bollocks - "it can never happen, but if it
> > does,
> > let's return -EWHATEVER to feel better". Some are crap like -EINTR, which
> > is
> >
On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote:
> Most of them are actually pure bollocks - "it can never happen, but if it
> does,
> let's return -EWHATEVER to feel better". Some are crap like -EINTR, which is
> also bollocks - for one thing, process might've been closing files precise
On 27/08/2019 20:27, Al Viro wrote:
<>
> If you want to express something like "data packet formed; now you can commit
> it and tell me if there'd been any errors", use something explicit. close()
> simply isn't suitable for that. writev() for datagram-like semantics might
> be; fsync() or fdatas
On Tue, Aug 27, 2019 at 06:01:27PM +0300, Boaz Harrosh wrote:
> On 26/08/2019 22:32, Al Viro wrote:
> <>
> > D'oh... OK, that settles it; exclusion with st_write() would've been
> > painful, but playing with the next st_write() on the same struct file
> > rewinding the damn thing to overwrite what
On 26/08/2019 22:32, Al Viro wrote:
<>
> D'oh... OK, that settles it; exclusion with st_write() would've been
> painful, but playing with the next st_write() on the same struct file
> rewinding the damn thing to overwrite what st_flush() had spewed is
> an obvious no-go.
>
So what are the kind o
On Tue, Aug 27, 2019 at 02:21:50PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 27, 2019 at 1:58 PM Al Viro wrote:
> >
> > On Tue, Aug 27, 2019 at 10:51:44AM +0200, Miklos Szeredi wrote:
> >
> > > How about something like this:
> > >
> > > #if BITS_PER_LONG == 32
> > > #define F_COUNT_SHORTTERM ((1U
On Tue, Aug 27, 2019 at 1:58 PM Al Viro wrote:
>
> On Tue, Aug 27, 2019 at 10:51:44AM +0200, Miklos Szeredi wrote:
>
> > How about something like this:
> >
> > #if BITS_PER_LONG == 32
> > #define F_COUNT_SHORTTERM ((1UL << 24) + 1)
> > #else
> > #define F_COUNT_SHORTTERM ((1UL << 48) + 1)
> > #end
On Tue, Aug 27, 2019 at 10:51:44AM +0200, Miklos Szeredi wrote:
> How about something like this:
>
> #if BITS_PER_LONG == 32
> #define F_COUNT_SHORTTERM ((1UL << 24) + 1)
> #else
> #define F_COUNT_SHORTTERM ((1UL << 48) + 1)
> #endif
>
> static inline void get_file_shortterm(struct file *f)
> {
On Mon, Aug 26, 2019 at 08:28:19PM +0100, Al Viro wrote:
> On Mon, Aug 26, 2019 at 11:20:17AM -0700, Matthew Wilcox wrote:
> > On Mon, Aug 26, 2019 at 05:29:49PM +0100, Al Viro wrote:
> > > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> > >
> > > > We might be able to paper ove
On Mon, Aug 26, 2019 at 09:34:37PM +0300, "Kai Mäkisara (Kolumbus)" wrote:
>
>
> > On 26 Aug 2019, at 19.29, Al Viro wrote:
> >
> > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> >
> >>We might be able to paper over that mess by doing what /dev/st does -
> >> checking that file
On Mon, Aug 26, 2019 at 11:20:17AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 26, 2019 at 05:29:49PM +0100, Al Viro wrote:
> > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> >
> > > We might be able to paper over that mess by doing what /dev/st does -
> > > checking that file_count(f
> On 26 Aug 2019, at 19.29, Al Viro wrote:
>
> On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
>
>> We might be able to paper over that mess by doing what /dev/st does -
>> checking that file_count(file) == 1 in ->flush() instance and doing commit
>> there in such case. It's no
On Mon, Aug 26, 2019 at 05:29:49PM +0100, Al Viro wrote:
> On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
>
> > We might be able to paper over that mess by doing what /dev/st does -
> > checking that file_count(file) == 1 in ->flush() instance and doing commit
> > there in such case.
On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> We might be able to paper over that mess by doing what /dev/st does -
> checking that file_count(file) == 1 in ->flush() instance and doing commit
> there in such case. It's not entirely reliable, though, and it's definitely
> not s
21 matches
Mail list logo
